Это взято с реального мира, где тоже много плагинов натыкано.
Вот так там запущен апач.
Timeout 2 KeepAlive Off ... <IfModule prefork.c> StartServers 1 MinSpareServers 1 MaxSpareServers 1 ServerLimit 1 MaxClients 1 ListenBacklog 4 MaxRequestsPerChild 300 </IfModule>
А так exim, чтобы память зря не расходовал
remote_max_parallel = 1
А еще я обычно запускаю vsftpd и sshd из inetd, чтобы не висели в памяти, когда не нужны. На шаред хостинге не подойдет такое, но на впсках это очень хорошо! Просто 512 памяти это уже и так завались, можно этого не делать.
А можно подробнее в чем была проблема огласить? Уже публично обсуждали, всем интересно.
Не будет никакого горя, если без коней в вакууме про горы параллельных запросов и каких-то надуманных тюнингов mysql.
Ден, вы правда считаете, что втирать всякую чушь потенциальным клиентам хорошо скажется на бизнесе?
А теперь по делу.
Апач.
Большинству сайтов с головой хватит одного, двух процессов апача. Одного, потому что запросы выполняются за миллисекунды и до 100 запросов в секунду там нечего параллелить, они сами придут в разное время, а кто пересечется, подождет своей очереди какие-то миллисекунды. А двух, потому что у некоторых иногда могут быть запросы, которые могут занять процесс на много секунд, например экспорт базы, и нужно чтобы в это время был один свободный, который примет обычные запросы. Но лучше все таки один, потому что и больше памяти останется под кэш фс и два и больше процесса все таки иногда усугубляет проблемы, например, когда что-то выполняется долго и кэшируется, при нескольких процессах может выполняться сразу на многих процессах и проедать ресурсы, а вдруг они ограничены, может начать тормозить.
Mysql.
Большинству сайтов для сервера mysql достаточно и 32 МБ, не нужно в ней пытаться ничего кэшировать и оптимизировать без реальных тормозов, не расходуйте зря память. Потому что важнее, сколько останется этой памяти под кэши файловой системы. Mysql, как и все, полагается на него для кэширования данных.
Остальное и итог.
50-100 МБ займет ядро вместе с буферами, nginx, sshd, vsftpd, exim, cron. 32 МБ mysql, 32 MB апач, Остается от 300 МБ под кэш файловой системы. А это означает, что при обычной нагрузке, когда большинство запросов приходится на маленькую часть контента, можно иметь контента (базу и файлов) на все доступное место на впске и ничего не будет тормозить и падать. Как-то так (взято с подобной впски):
zcat /var/log/nginx/access.log-20150605.gz | wc -l
63279---------- Добавлено 05.06.2015 в 15:01 ----------
Без ума ничего никогда не хватит.
Как что-то может упасть от f5, расскажите? Или это вы примеряете к самой кривой системе в мире с лимитами в стиле клаудлинукса?
512 на 32 битной оси с головой для сайтов.
Apache вместо php-fpm лучше, потому что поддерживает .htaccess, а по производительности они одинаковы.
Маловатый кусок скопировали, но судя по этому, временные файлы для прокси могут не закрываться, дальше там нигде нет закрытия файла 445:
open("/var/lib/nginx/tmp/proxy/7/46/0000054467", O_RDWR|O_CREAT|O_EXCL, 0600) = 445
unlink("/var/lib/nginx/tmp/proxy/7/46/0000054467") = 0
Почему это может происходить: неправильно настроен nginx, сторонние модули nginx неправильно с временными файлами проксирования работают, баг.
Нужно смотреть конфиг nginx, с какими модулями собран и т.д.---------- Добавлено 04.06.2015 в 18:22 ----------Напишите сюда, там вам помогут найти проблему в nginx, мне в его кривостях не хочется копаться:
http://forum.nginx.org/list.php?21
С этими желательными только реселлер будет.
У digitalocean можно запустить виртуалку в тех краях, но paypal, карточки и англоязычный.
отрывки и нужны, он ведь бесконечный
strace -e open,openat,close,unlink,unlinkat -p 26711 > /tmp/strace.out 2>&1
подождать немного, остановить и потом
less /tmp/strace.out
По аналогии, что бы говорили, если бы вам домашний провайдер отрубил интернет, за то что вы превысили лимит, или еще интереснее, выборочно обрывал закачки с сайтов :D
Придумывайте лимиты, что можно сказать. Чем больше таких хостеров, тем меньше конкурентов у нормальных.
Тогда может ТС ошибся хостингом, не на того жалуется :)