Все-таки - поболее будет, чем для активных, не?
Разделяемая память? Этим, мягко говоря, пользуются. MPM очень активно делают независимыми и привязка модулей к конкретному - не приветствуется.
Просто обычно под "стандартным" - подразумевается что-то распространенное, популярная модель. Назвать таковой подход nginx - покуда сложно. Сколько там? - 8% на _нагруженных_ сайтах. А остальное - нешто IIS?
При каком? Что-то мне подсказывает, что в роли бакенда эта модель покуда редкость. Это случайно?
Работает - не трогай.
Но может и попробую как-нибудь - в тестах смотрится вполне нормально. Плюс, в Debian сейчас можно относительно удобно несколько копий апача запустить. Не нужно гемороя со сборкой пакета nginx, etc. И модулей под апач немало вкусных.
df -h
dmesg
вывод atop
Хватит уже притчами вещать, на Христа не тянешь ;)
Избы ты сам строить будешь. А здесь речь шла о работе кеша VFS - проблема в том, что ты этого не понял и пошел вещать прописные истины о совершенно другом.
Пусть меня поправит ТС, но я думаю - он знает как управлять кешем "некрасиво". Грубо говоря - запихивать файл в кеш скриптом. Боюсь, в ситуации ТС больше "настраивать нечего", как заметил netwind.
Лично у меня после "откровения" о vm.swappiness и vm.vfs_cache_pressure - желание "обращаться" пропало полностью.
Патомушта вычитал эту "универсальную" рекоммендацию в каком-то говноблоге. Не?
Может будет полезно. Есть такая штука, systemtap:
http://sourceware.org/systemtap/wiki/WSCacheHitRate
PS: Применять с осторожностью, беречь от детей.
Нееет, дядинька. Вы заявили только вот цифирь:
Не всех/не всегда, ЕМНИП.
Стандартная модель - вовсе не эта. Стандарт - это апач. А lighttpd, squid, varnish, nginx - как раз "менее известные программы".
Наверно, их назначение наводит на мысль об ограниченности подобной "стандартной модели"? Или то, что это раздавалки статики да прокси/кешеры - абсолютно случайное совпадение?
Сокращаются _от чего_? Напоминаю, в апаче тут тоже только один поток.
Переключение контекста. "Созданием" потоков апач занимается только тогда, когда сконфигурирован неправильно, или нагрузка резко подскочила.
Согласен, хотя думаю что в отношении памяти Вы погорячились. Расход памяти на служебную информацию для создания потока - действительно может быть порядка той, что затрачивается на обработку запроса?
Неправда. Я Вам объяснял уже, что неактивные KeepAlive соединения - обслуживаются в одном потоке.
Допускаю, конечно, что nginx для хранения данных этих соединений использует какой-то шибко эффективный в отношении памяти мегаформат. Но профит явно будет не в разы и даже не с существенным коэффициентом.
Ага... Т.е. все-таки - дело-то не в памяти.
Кстати, недостатки этой модели тоже "очевидны". Один из них Вы уже приводили.
У... как все запущено.
Согласен. Шеф, мы это знали (скажу и за alw - вряд-ли промахнусь ;)).
Ну дык почитать надо энтот "официальный сайт", ага. Не осилите ссылку "Bug Reports" найти - мы поможем убогим...
Т.е. не знаете?
Для неактивных соединений в keep-alive - тем более неинтересно. Здесь разница вообще стремится к нулю, если вообще есть.
Идете в багзиллу и смотрите подробно. Если есть актуальные для Вас проблемы - не используйте.
Насколько я знаю (об этом спрашивали в рассылке), просто этот модуль появился в 2.2 - вот только потому и помечен "экспериментальным".
myhand добавил 21.11.2011 в 20:25
Что-то я не понимаю. Либо гипотеза верна - и Вы просто заменили одного апача на сякую-вот связку. Либо я ошибся в отношении Вас. В чем неправда-то?
Если я таки прав, то поставь nginx перед апачем (или второй экземпляр апача) - эффект был бы практически тот же самый.
Ну, число _потоков_ у апача - тоже конечно. Поскольку речь идет именно о потоках - оверхед в отношении памяти сравнительно небольшой, если вообще заметный.
Внимание, вопрос. Насколько серьезна экономия в ресурсах (речь пока зашла только о памяти)? В цифирях - процентах, разах, попугаях.
"Традиции" nginx таковы, что его называют "a horrible hairball of code" в апачевской рассылке.
Помним про "корень всех зол" и бесплатный сыр в мышеловке? ;)
Поставили бы фронтендом апач (с тем же воркером или, лучше, mpm_event) - получили бы ровно то же самое.
Достаточно скромно. Абсолютно не вижу, почему апач вместо php-fpm у Вас не справлялся. Моя гипотеза: бездумная настройка по какому-то хавту (был один апач - стал nginx+etc). Не?
