Своп подключается на ходу с помощью swapon.
А вот по поводу помогает-ли, это большой вопрос.
Смотря чему... Если у вас постоянная нехватка памяти, то вам своп ничем не поможет - доступ к диску намного медленее, чем к оперативке, к тому же вы ещё увеличиваете нагрузку на диск. Обычно тогда когда начинает использоваться свап, сервер тихо умирает под нагрузкой, т.е. использование свопа проблему только усугубляет, и получается эффект снежного кома.
Скорее всего, вам надо разобраться с тем, сколько памяти выделяется тем или иным процессам.
Самая частая ошибка, это огромное ограничение на количество процессов апача, каждый из которых отъёдает немалый кусок оперативки, особенно когда в конфиге болтается пачка не нужных модулей, подключённых по умолчанию. Mysql тоже может немало скушать при неумелой настройке, или наоборот не кушать почти и тормозить всё, заставляя плодиться тот же апач.
Причин может быть немало, надо внимательно всё смотреть.
Ограничения в итоге должны быть такими, чтобы при максимальном количестве процессов, с максимальными лимитами потребления памяти на процесс у вас оставалось хотя бы немного свободной памяти на кеширование файловой системы.
На ваш вопрос, в общем-то, не существует корректного ответа. Сайт на одной и той же CMS может отличатся по потреблению ресурсов на порядки.
Разных плагинов кеширования под вордпресс море, и работают они по-разному.
А вам надо на самом деле поискать узкие места, и определиться, что нужно сделать - внести какие-то изменения в сайт или настройки сервера или добавить ресурсов.
А теперь вообще выкидываем apache, ставим nginx, без лишних модулей, php-fpm, и радуемся.
Чем на ваш взгляд, этот вариант хуже, чем apache worker + fcgi, или lighttpd + fcgi?
Особенно, если учесть, что нити + их буферы занимают всё же больше чем буферы nginx, который не плодит процессов и нитей при увеличении количества соединений.
А lighttpd, кстати говоря, то ещё поделие.
Это весьма полезная оптимизация, если она возможна, но всё же не борьба с атакой.
По этим дистрибьютивам банально больше всего информации, и меньше всего сюрпризов с версиями пакетов.
Какие дистрибьютивы предложили бы начинающему вы?
Можно использовать и другие, Gentoo например, и пусть ТС застрелится? =)
Самые распространённые варианты и логичные CentOS и Debian.
Мне нравится Debian. =)
На стороне php:
- max_execution_time Максимальное время исполнения скрипта
- max_input_time это время, которое php может затратить на обработку входящих данных, т.е. заполнения данными структур до запуска собственно скрипта, и это ограничение очень радко чему-то мешает.
На стороне nginx (если если используется php через fsatcgi):
- fastcgi_read_timeout Время ожидания начала ответа от скрипта.
Ещё браузер дальше имеет свои таймауты, так что очень уж долго не получится скрипт выполнять. =)
Разумно, но тогда надо подробно расписать, что надо бекапить, как часто, какой объём данных и.т.п. Тогда вам можно посоветовать какое-то решение готовое.
Выше были ссылки, подкину ещё http://duplicity.nongnu.org/ - может делать инкрементальные бекапы и сохранять их на ftp сервере, + при необходимости в зашифрованном виде. Применимо, если нужно периодически бекапить немалые объёмы и/или иметь версионность.
А вообще решений много, от элементарных, до довольно навороченных - найти несложно для любых целей, лишь бы понимать, что нужно-то. =)
Если не обращать внимания на то, что качество каналов провайдеров всё же куда хуже, чем в дц, то всё примерно так, но т.к. у вас php, а не .net и MSSQL, то наиболее разумным первым шагом будет установка Linux, а не windows 2008 server, т.к. при прочих равных производительность будет выше, хотя если нагрузки большой не будет и вы умеете администрировать windows сервер, то можно сделать и так, как вы описали.
Если вы не умеете администрировать ни то ни другое, всё же стоит поставить Linux, банально проще будет найти примеры конфигурации, а объём информации, который надо будет перелопатить и осмыслить, будет примерно одинаков.
А в целом список примерно правильный.
Почти, так, если опустить разные тонкости, т.е. в случае с nfs, на той машине куда вы её экспортируете, вы работаете с удалённым диском, и гоняете всё чтение и запись по сети, запись ещё возвращается по сети к вам на drbd slave.
В случае с ocfs, оверхедом будут служебные данные - блокировки и.т.п, которых обычно куда меньше, а не все данные. И читать вы будете с локального диска, что уменьшит задержки. Если один из дисков в drbd отвалится, у вас перераспределится нагрузка, и вы будете работать примерно так, как было бы с экспортированным по nfs диском.
Если в вашем варианте отвалится мастер drbd, что будет? =)
