zuborg

Может быть ещё sata контроллер работает в ide режиме (в bios настраивается), или драйвера на него (или чипсет) не установлены. Сам bios тоже не мешало бы обновить, если есть свежий.

Любой, после перепрошивки dd-wrt, например.

Для SSD TRIM не может быть не нужен. Было дело что в X25-M G1 (первое поколение) TRIM не поддерживался, но это исправили в G2 дисках. Так что если поддержка есть, то лучше её активировать и использовать.

Скорее всего у Вас label битый, со слайсом размером в 180Г на винте меньшего размера, либо с началом слайса большим чем надо. Итого gpart детектит по таблице bsdlabel слайс обьемом 180Г и создает блочное устройство с соотв характеристиками. А запросы dd проходят к физическому диску и доходят до его конца раньше, чем достигнут конца слайса.

Очень сильно зависит от нагрузки.

Увы, но ZFS многопоточную загрузку (когда десятки процессов одновременно хотят что-то прочитать с винта) держит крайне плохо. Если нет цели хранить очень-очень большие обьемы — рекомендую gmirror на 4 винта, ну или zfs raid1 на 3 винта + ssd под zil — так будет быстрее всего на чтение, при умеренной записи.

Опять же, raidz для контейнеров дисков навряд ли сильно нужен, там скорее стоит использовать gpart и експортить в виртуалку сырой раздел.

Разумеется перестраиваются, если они активны (не использовалось alter table… disable keys).
Другой вопрос, что их апдейт забирает ресурсы, и если для «очень быстро» индексы поотключать, а потом включить обратно — это повлечет за собой полный ребилд индексов, что может быть напряжно, если данных было очень много, а добавлено сравнительно мало.

посмотрите ещё на Percona XtraBackup, может пригодится

Хочу сразу все сделать правильно
Все хотят, да вот ни у кого не получается ;)

стоит ли тогда заморачиваться с выбором базы данных?
Разумеется, хранить надо в отдельной базе данных, можно и файловой. А то когда захочется шаблон html-ки поменять, будет не смешно.

Казалось бы, что может быть проще и легковеснее, чем отдавать статичные .html файлы
Собственно, ничего, поэтому для незалогиненых пользователей, которые генерируют 90% трафика, стоит использовать именно статичные .html файлы. Запросы пользователей, которым надо генерить индивидуальные странички, надо направлять на движок в обход кеша (например, по факту наличия соотв сесионной куки).

Где лучше хранить кэш с .html документами?
в соотв. documentroot, чтобы nginx мог их легко найти и отдать, прямо по запрашиваемому урлу. Крайне желательно поддерживать некоторую вложенность папок, чтобы в каждой папке было максимум несколько тысяч файлов или других папок.

Или может все хранить в тех же файлах?
Все нельзя. Только то что редко обновляется и долго остается валидным. Для короткоживущих данных лучше использовать все-таки memcached, во избежание лишней нагрузки на диск. Либо FS в памяти, если уж хочется работы с файлами. Для короткоживущих данных в php есть замечательное средство кеширования — pecl модуль APC (основное его предназначение opcode cacher, но данные он тоже может кешировать)

У работы с файловым кешем свои тонкости. Например, данные в нем менять надо атомарно, т.е. через временный файл и последующий rename(). Также желательно использовать блокировки чтобы избежать ситуации, когда несколько запросов паралельно начинают генерировать один и тот же элемент кеша. Часто нет необходимости немедленно перегенерировать элемент кеша при обновлении данных, достаточно его удалить, а генерация произойдет при запросе.

Форматировать однозначно стоит, ОС пошлет команду TRIM на нулевые блоки (если соотв. поддержка в ОС есть, конечно), и тогда ssd будет знать что эти блоки можно использовать немедленно, вместо того чтобы пытаться отложить запись на них.

Вполне может быть что эту ошибку генерирует апач, проверьте post_max_size в php.ini, и error логи nginx-а и апача, также сравните access-логи для Вашего запроса в nginx-е и апаче

Не примите за занудство, но bash (и другие sh) не умеет заходить на ftp. Вам необходимо использовать внешнюю программу, которая это умеет, и тут начинаются зависимости от версии Вашей ОС, что установлено и что можно установить и т.д. и т.п. Уточните вопрос.

btw, если есть возможность логина по ssh вместо ftp, то вопрос решается легко через
find /path/to/dir -type f | wc -l
Всяко производительней делать подсчет на стороне где лежат эти файлы, вместо пересылки списка файлов. Кроме того, команда dir протокола ftp не делает рекурсивный листинг, так что таких команд придется прогнать столько, сколько найдется поддиректорий, это дополнительные тормоза.

Направлений действительно много, но есть один общий принцип — все эти книжки, статьи и прочие теоретические знания без практики не стоят и ломаного гроша…
Короче — внедряйте в жизнь полученные знания. С умом, разумеется, а не сломя голову все подряд и как попало. Полученный опыт дополнит теорию, вот тогда и будет толк. Заодно и будет возможность определиться с тем что ближе к душе и легче дается.

Если так стоит вопрос, то просто сделайте обертку для куска кода, который получает запросы снаружи, и добавьте в нее поддержку разных режимов/протоколов. Список более-менее актуальных протоколов взять у того же nginx-а. Для универсальности (но, увы, не производительности) добавьте ещё cgi — он везде есть.

PS. fcgi старое проверенное производительное решение, сомневаюсь что в ближайшее (или не очень ближайшее) время что-то станет более популярным и производительным.

mysqladmin variables | grep timeout

Дробить надо, причин тому много, фактически все сводится к тому, что чем больше обьектов в папке — тем больше ресурсов надо на их поиск (и другие операции). В некоторых случаях — пропорционально размеру…
Найти файл (или пустое место для создания нового) среди миллиона таких же в папке сложнее, чем сначала найти его подпапку среди тысячи подпапок, и потом найти нужный файл среди тысячи в выбранной подпапке. Даже с техниками индексирования содержимого папок…

Итого, желательно чтобы максимальное кол-во обьектов в папке было порядка 1к-5к. Добавлять односимвольные подпапки, к примеру, не эффективно — их получится много и кол-во операций поиска елемента в папке сильно увеличится (хотя операции эти будут сравнительно простыми). Идеально — 3 (максимум 4) цифры на подпапку, либо 2 символа включая буквы (для равномерной плотности распределения символов в имени).

Может сделать триггер на insert на основную таблицу, который будет копировать строку в архивную таблицу. delete соотв оставлять без внимания. update/replace — смотрите сами.
Основные запросы делать на основную таблицу, а для отчетов — на архивную.

Если воркер из реального затраченного времени на обработку запроса использует в среднем только 25% cpu — значит воркеров стоит запускать в четыре раза больше чем кол-во ядер. Плюс-минус. Обычно ещё есть дополнительная нагрузка, типа баз данных, поэтому можно выставить немного меньшее значение.
Для воркеров, которые эффективно используют cpu, не блокируясь в процессе работы, соотв надо выставить просто кол-во ядер.

Лучше использовать кластер серверов — и надежнее, и дешевле, чем покупать один супер мощный сервер.
В мейнстримовых серверах по две 1Г сетевухи, их можно обьединить и получить 2Гбита на сервер (реальных 1.5-1.8 без потерь покетов)
Опять же, современные недорогие 1U корпуса вмещают 4 винта, вполне нормально для поставленой задачи, можно даже все объединить в raid1 для увеличения производительности чтения.
Проц совершенно неважен для отдачи статики, лучше взять меньше ядер — но больше частоту — положительно скажется на скорости обработки сетевых прерываний.
Памяти стоит напихивать по максимуму, для мейнстримовых мамок это 16Г.
Обязательно обратить внимание на сетевухи, это должны быть либо интел, либо броадком, ни в коем случае не реалтек и прочие марвеллы.
Балансить траф надо не рандомно, а так чтобы один и тот же файл отдавался с одного и того же сервера — так более эффективно используется ram под файловый кеш, грубо говоря — суммируется по всем серверам.
ssd — отдельная песня, в Вашем случае (маленький объем контента) возможно даже более предпочтительнее взять один ssd на 480G за 500уе, чем 4 винта, можно и на памяти сэкономить.

В общем, это уже cdn, возможно Вам будет проще и выгоднее воспользоваться уже работающими на рынке cdn сервисами.

Вообще-то толстый кабель это как раз гут, он более надежный и сопротивление меньше. Аудиофилы так те вообще считают, что меньше 2 мм квадратных площади в сечении на проводник нельзя и близко к аудиотехнике подносить…

А вот длину лишнюю убрать не помешает.

В принципе, наверное лучшим вариантом будет поискать не сильно дорогой аудиокабель для bi-wiring с сечением порядка 1мм на проводник — в нем будет 4 жилы, и надо чтобы можно было разделить две пары жил, т.к. у Вас наушники с раздельным подводом кабеля.