Армянское Радио, Да, можно собрать с помощью LVM что-нибудь типа 2-3хRAID10 в один блок, что не решит полностью проблемы, и скорее всего, уменьшит скорость. А можно и с ZFS пожить, хотя с ней всё не так уж радужно.
Но, часто, деградация 10 и его перестроение, при замене диска, не вызывает большой проблемы. 1,8тб скопировать даже под нагрузкой не так и долго, тем более на SAS. Эта проблема больше при больших и медленных дисках проявляется.
И я не рекомендовал 5, я написал, что он, в частности, влезает по объёму. Автору всё равно надо хорошенько почитать, чтобы принять разумное решение. И отнюдь не только наши комментарии...
Армянское Радио Часто, достаточно купить что-то не экзотическое, что наверняка будет в наличии.
Не все сервисы обязаны иметь такую уж высокую надёжность, чтобы держать запас контроллеров, а те, что обязаны, не собираются вот так на одном сервере кем-то кто не знает что делать, обычно.
К тому же, дорогие рейд контроллеры, на которых, собственно, имеет смысл собирать хардваный рейд, довольно надёжны, особенно, в сравнении с материнкой от asus, и не понятно какими комплектующими, которые к ней подключены, и не он будет тут наиболее вероятной точкой отказа. =)
hsadik Raid 5,6,10 влезает в 10TB, при таком объёме и кол-ве дисков. Raid 10 будет быстрее всего (12x read, 6х write), и экономнее по вычислительным ресурсам, но 1 диск до отказа.
Совсем не обязательно использовать ZFS - можно собрать RAID на железке, если будет приличная куплена, или с помощью того же mdadm, но конечно не RAID1, и стоит почитать о уровнях RAID, и выбрать нужный для задачи.
Это будет шустрее чем ZFS, во многих случаях, да и экономнее по потреблению памяти.
А LVM, может нужен, а может и нет - тут вопрос что там, и как будет хранится.
Opcache просто безусловно нужен - разницу будет видно не вооруженным взглядом... =)
Для поиска есть solr, sphinx и.т.п. - намного эффективнее чем mysql like запросы. Это может очень заметно уменьшить нагрузку, и качество поиска улучшить, кстати. Я не сталкивался, правда, с реализацией поиска WP на этих движках, но наверняка есть готовые решения.
300% mysql, это загрузка всего трёх ядер, что вероятно, не так и много.
А что делает php при загрузке средней страницы, неплохо бы выяснить при помощи профайлера, и возможно найдётся что-то, что можно очень здорово оптимизировать...
Александр Гетманский, В случае применения внешнего кеширования, у вас есть, фактически, только одна стратегия - ttl.
При этом, почти всегда, выгоднее инвалидировать кеш по изменению данных, или возникновению какого-либо события, чем по интервалам времени. А регенирировать в один поток, не конкурентно.
Этого можно достичь на стороне приложения, но нельзя на стороне внешнего кеша. Так что ни к какому "ворожению" это не имеет отношения.
Я бы не использовал ни SSI, ни Varnish если бы не писал приложение с нуля, и имел бы полный контроль над ним.
Но и в этом бы случае не использовал, т.к. можно было бы реализовать куда более эффективную стратегию кеширования на стороне приложения.
Varnish почти всегда, в итоге, потраченная без пользы память, которую лучше было бы отдать куда-нибудь ещё.
Чтобы SSI работал, у вас должны быть запросы, которые вернут _только_ содержимое нужных на странице блоков...
И они должны суммарно, быть намного эффективнее, чем тот, что вернёт страницу, учитывая кеширование на стороне приложения, чтобы это имело бы вообще смысл.
Этого не так и просто добиться, т.к. на каждый такой запрос придётся загрузить данные, как минимум, о сессии, пользователе, и его правах, из базы + данные которые надо вернуть.
Что ssi, что varnish с его esi, это не серебряная пуля, и не решение, которое можно просто включить. Они требуют поддержки со стороны приложения, и имеют огромный минус - они не знают, как инвалидировать кеш, кроме как по TTL, а это не самый эффективный путь. По изменению данных инвалидировать кеш можно куда реже, например.
/etc/sysconfig/iptables вроде, ipset где-то там рядом.
Но если вы ничего не настраивали кроме установки правил через консоль, то вероятно, они не сохранены вовсе.
Это зависит от того, какая у вас операционка, и какой инструментарий управления фаерволом вы используете - вариантов просто масса, на самом деле...
Возможно, даже нигде не хранится, если вы не устанавливали какой-нибудь фаерволл, типа ufw, или какой-нибудь perist-iptables, и просто достаточно перезагрузиться...
Это зависит от того, на чём вы пишите. В ассемблере есть соответствующая инструкция, а в С, обычно, есть макрос. В языках более высокого уровня, я не представляю, зачем может понадобится такая короткая задержка в принципе. =)
Но, часто, деградация 10 и его перестроение, при замене диска, не вызывает большой проблемы. 1,8тб скопировать даже под нагрузкой не так и долго, тем более на SAS. Эта проблема больше при больших и медленных дисках проявляется.
И я не рекомендовал 5, я написал, что он, в частности, влезает по объёму. Автору всё равно надо хорошенько почитать, чтобы принять разумное решение. И отнюдь не только наши комментарии...