Думаю, имелось в виду, что мы не знаем, чем вы занимаетесь на этом компьютере. Считаете физические или биологические задачи, подбираете хэши паролей, играете в Веселого Фермера, или читаете ХабраХабр. От этого и зависит ответ.
О, еще один мастер строить велосипеды. И nginx мы перепишем, и кэш свой собственный напишем, нельзя же полагаться на кэш ОС, который писали неграмотные криворучки!
Интересно, сколько лет пройдет, прежде чем придет понимание, что велосипеды с квадратными колесами не летают, и чаще всего рассыпаются при первой попытке поехать.
С открытыми драйверами мой ноут греется на 10-12 градусов сильнее, чем с закрытыми, достал постоянный визг кулера. С catalyst'ом кулер почти неслышен, и, хотя сам каталист мне не нравится, пришлось все же на нем остаться.
Практически любая работа подразумевает работу с текстом. Широкие и короткие тексты читать очень неудобно. Если текст не занимает всю ширину монитора, то по вертикали влезает лишь небольшая часть. Это особенно неудобно при программировании — чем больший кусок программы можно охватить взглядом без прокрутки, тем эффективнее работа. При работе с документами то же самое.
Единственное достоинство широкоэкранных мониторов — можно расположить два документа рядом. Но лично я с такой необходимостью сталкиваюсь нечасто, к тому же ширины нормального монитора хватает.
Найти монитор не 16:9 весьма и весьма непросто. Почему-то эти горе-маркетологи считают, что все мониторы покупаются для просмотра фильмов, а не для работы.
А может быть, потому что их производят в странах, где использовалось до недавнего времени вертикальное письмо.
Как разработчик одного из высоконагруженных серверов могу сказать, что ORM ничуть не мешает. Правда, использую PostgreSQL, а не MySQL, но думаю, не суть важно.
Неэффективные запросы генерируются редко и обычно ситуацию можно исправить не прибегая к сырому SQL. Ну что там такого можно наворотить на голом SQL, что нельзя сделать в ORM? Да почти ничего.
Лишние JOIN'ы написал для примера, такие случаи в практике бывали, но редко, и не оказывали влияния на производительность. Если ORM джойнит таблицу с миллионами записей, когда это не нужно, то на помойку надо отправлять именно эту реализцаию ORM, а не всю концепцию в целом.
По поводу NoSQL: полагаю, что на каждый пример этих деплойментов, найдутся тысячи, даже десятки тысяч аналогичных проектов на SQL. Мне казалось, что общепринятое мнение сейчас, что NoSQL не стали очередной серебряной пулей. Где-то они лучше, где-то хуже, где-то равны.
Ага, facebook, friendfeed, quora, и другие — просто ошибаются.
Да и ORM никто не использует. Чем вам так ORM не угодил? Неужели такая большая разница с написанным вручную запросом? Нормальный ORM обычно позволяет построить практически любой запрос, разница с написанным вручную — минимальная. В худшем случае будет лишний JOIN или браться несколько лишних полей — это незаметные копейки в потере производительности.
Честно говоря, ничего не приходит в голову.
Есть еще варианты:
— запустить падающий процесс в gdb, если gdb установлен, и после падения посмотреть backtrace
— забжкапить /home и переустановить систему
Тогда strace и/или попытаться вручную установить самую свежую libc.
Насчет памяти — я бы ее все же проверил. Хотя бы 10-15 минут. У меня был ноут, привезенный из Франции, в котором стояло две планки, и обе были битые. Проявлялось это изредка, сложно было понять, в чем дело. После замены памяти год нет никаких проблем.
> вряд ли. Вы же можете, например, с hdd, подключённого по USB посмотреть Full HD фильм. Причина, как мне кажется, не в пропускной способности
При просмотре фильма с диска поток передаваемой информации меньше, так как фильм сжат. Думаю, что камера передает несжатый поток видео, а если и сжатый, то незначительно.
То, что возникла мода на NoSQL не означает, что это панацея и xSQL можно хоронить. Многие высоконагруженные сервисы работают без NoSQL (Skype использует PostgreSQL, например). Биллинги опсосов работают на SQL (это, правда, не совсем веб-сервис, хотя веб-составляющая там присутствует, но нагрузки там ого-го). SQL тоже масштабируется.
Мне кажется, что шумиха вокруг NoSQL рано или поздно уляжется, как это было почти со всеми «серебряными пулями».
Ну, да, redis похож на memcached с сохранением на диск. Впрочем, в отличие от memcached он поддерживает более сложные типы данных, и формально относится к NoSQL. На нем одном можно построить довольно нетривиальное приложение.
Остальные NoSQL решения толком не щупал. Игрался с CouchDB и Mongo, но только игрался. Про Mongo не раз читал, что если объем базы превышает размер RAM, то наступает задница. Меня такие решения не интересуют — если бы у нас был бюджет на сервера с 32-64 Гб RAM, то на них и PostgreSQL летал бы, без мучительного переписывания приложения.
Я не могу. Экспериментировал с Redis, результаты были многообещающие, но redis — почти то же самое, что memcached. Все данные хранятся в памяти, поэтому нужны сервера с огромными объемами RAM (начиная с 8-16 Gb). Начальство не дало добро на такое расширение. К тому же, сохранение на диск у него все же кривоватое.
Как я понимаю, у всех NoSQL все хорошо до тех пор, пока данные помещаются в RAM. По крайней мере, у MongoDB такая же проблема судя по тому, что читал.
В общем, планирую перенести лишь маленькие части сайта, типа различной статистики, на redis.
Кстати, в redis удобнее кэшировать некоторые вещи, чем в memcached, из-за того, что данные не теряются при перезагрузке и из-за того, что поддерживаются сложные типы (списки, словари). Можно не удалять/переписывать данные при каждом изменении, а, допустим, обновлять список при появлении нового элемента.
Под статикой понимается HTML, CSS и медиа-контент. Да, в нашем случае он отдается напрямую в виде файлов без проверок ACL. Если нужно проверять, то для nginx существует какой-то модуль, реализующий такие проверки, просто в нашем случае это непринципиально.
Почему важно думать о кэшировании: во-первых, первый раз кто-то должен заполнить кэш. Это значит, что как минимум один пользователь должен подождать длительное время. А если каждому показываются разные данные, значит каждый как минимум один раз должен будет ждать (на самом деле, более одного раза). Поэтому кэш — не панацея. Во-вторых, инвалидация — чертовски сложная вещь. Если удалять из кэша изменившиеся данные слишком часто, то не будет никакого выигрыша от кэширования. Если слишком редко или забыть где-то вызов инвалидации, то пойдет волна жалоб от пользователей на то, что они что-то делают, а результат не видят. Когда есть много связанных сущностей, чистить/обновлять кэш становится очень сложно, легко можно забыть о каком-нибудь условии.
Различные автоматические решения, в случае с нашим проектом на Django, это например johnny-cache, работают только в простейших случаях. Они все равно забывают периодически очистить кэш, и даже несмотря на вручную расставленые cache.delete пришлось отказаться от johnny-cache и ему подобных. Потому что проблемы все равно возникают, и решить их намного сложнее, чем исправить свой код.