Да, часов 9 назад.
Boris A Dolgov добавил 15.07.2010 в 12:06
Надо в ssh вбить команду, которую Himiko написал.
Нет.
Если файл имеет расширение, похожее на статическое - например, .jpg, .png, .zip и так далее, то он отдается через nginx.
В противном случае - через apache.
Boris A Dolgov добавил 15.07.2010 в 11:49
А что там такого было? Я юзал nginx оттуда, пока не собирал свой, вроде бы, багов не было.
Тема об этом есть на форуме ISPsystem: http://forum.ispsystem.com/ru/showthread.php?t=10149
Думаю, там будут самые свежие обновления.
apache всегда будет есть много ресурсов.
Главное, что теперь статика отдается nginx'ом, и keepalive/отдача страниц обрабатывается им же.
Должен снизиться расход памяти и немного спасть общая нагрузка.
Штатными средствами - нет; nginx ходит к бекенду по http1.0, и каждое подключение привязано к запросу. Есть патч от mdounin, но он в основном для memcached, и он не рекомендует использовать его для proxy. Или есть еще какая-то сторонняя наработка?
nginx не использует keepalive при хождении к apache.
при хождении клиентов к nginx с keepalive это ест считанные килобайты памяти.
Домен не обязательно должен быть на том же сервере - достаточно создать правильные A-записи там, где сейчас находится Ваш домен.
Так же, в случае создания ns, надо будет прописать их в NSI-реестр, так как в противном случае туда нельзя будет делегировать некоторые домены. Это надо сделать у регистратора; у нормальных эта процедура бесплатная.
То же самое применимо и к хостнейму: главное - создать A-запись, указывающую на главный ip сервера.
Пример:
1.1.1.1 - главный ip сервера
2.2.2.2 - второй ip сервера
В зоне domen.com должно появиться:
ns1 IN A 1.1.1.1
ns2 IN A 2.2.2.2
server IN A 1.1.1.1
После прописывания ns1 1.1.1.1 и ns2 2.2.2.2 в NSI, на него можно будет делегировать домены.
Ну, мои ответы будут получше, чем "Пешыти, рас биремься платна". А тот ответ являлся рекомендацией использовать nginx-0.8, который скоро станет stable вместо nginx-0.6, в который уже давно не бекпортят багфиксы и не добавляют функционал, данный в шутливой форме.
Давайте. PHP изначально был рассчитан и писался под web и cgi, где процесс живет секунды, и сразу умирает. Поэтому, там классически есть места, где что-то не подчищается (конечно, это фиксится, и заметно нафиксено за последнее время), не возвращаются sbrk/malloc, и так далее. При использовании php-as-cgi это не возникает, при использовании mod_php или fastcgi - возникает. Кроме того, подключена куча модулей, в которых тоже может быть как-то накосячено. Не исключено, что у ТС в скриптах используется что-то странное, что и вызывает наружу этот баг.
MaxSpareServers - 10, MaxClients - 150. Я не понимаю, почему из этого следует, что система не справляется - лишних процессов не будет, апачем запрос обрабатывается короткое время, так как nginx проксирует на него. Вывод - после нескольких событий, которые происходят периодически, процессы apache, которым хватало памяти, забирают себе лишнюю память, после чего ее хватать перестает. Один путь решения - перезапустить apache, другой - перезапускать отдельные его процессы, или, например, снимать kill'ом самые дорогие по памяти процессы.
keepalive и nginx - что Вы курите? :)
А при чем тут nginx? Он ограничивает количество одновременных запросов к apache (конечно, если так настроено), а внутрь apache он не лезет.
Почему-то Вы считаете, что PHP, apache и все библиотеки работают идеально и как написано в конфиге, а проблема в посещаемости и нагрузке. Я же не исключаю вариант с первой проблемой, и поэтому интересуюсь результатом установки MaxRequestsPerChild.
Кстати, интересный вопрос к ТС: память "размазывается" по процессам apache равномерно, или выделяется какой-то один процесс, съедающий ее всю?
Сапа - это вообще зло. Вторая часть лишняя :)
madoff, на каждую тему достаточно одного спамно-рекламного поста, полного грамматических ошибок.
Установка MaxRequestsPerChild не помогла?
