Pilat: Обычно нет, но он может это делать, если специально попросить.
Штатными средствами - нет; nginx ходит к бекенду по http1.0, и каждое подключение привязано к запросу. Есть патч от mdounin, но он в основном для memcached, и он не рекомендует использовать его для proxy. Или есть еще какая-то сторонняя наработка?
Домен не обязательно должен быть на том же сервере - достаточно создать правильные 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, на него можно будет делегировать домены.
да уж, ваши ответы содержательней, я наблюдаю, типа epel Отстой, alt Рулит. Я лучше буду
помогать чем блеск наводить на своих словах, тут видно кто чего стоит, мы же всё понимаем :) уважаемый Долгов :)
Ну, мои ответы будут получше, чем "Пешыти, рас биремься платна". А тот ответ являлся рекомендацией использовать nginx-0.8, который скоро станет stable вместо nginx-0.6, в который уже давно не бекпортят багфиксы и не добавляют функционал, данный в шутливой форме.
madoff:
давайте Долгов будем реалистами вы советуете "MaxRequestsPerChild " это смешно рассчитывать на то что у него утечка памяти в библиотеках или хз ещё где, тут если кто и написал что то то, в плане макс клиент было более верное направление, но снова таки TC сказал что стоит у него NGINX значит у него уже всё оптимизированный.
Давайте. PHP изначально был рассчитан и писался под web и cgi, где процесс живет секунды, и сразу умирает. Поэтому, там классически есть места, где что-то не подчищается (конечно, это фиксится, и заметно нафиксено за последнее время), не возвращаются sbrk/malloc, и так далее. При использовании php-as-cgi это не возникает, при использовании mod_php или fastcgi - возникает. Кроме того, подключена куча модулей, в которых тоже может быть как-то накосячено. Не исключено, что у ТС в скриптах используется что-то странное, что и вызывает наружу этот баг.
madoff:
что видно из следующего поста.
<IfModule mpm_prefork_module>
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 150
MaxRequestsPerChild 0
</IfModule>
У него уже всё по минимуму, не у желе вы Долгов это не видите, если уменьшение макс клиента не помогает значит у него система не справляется с нагрузкой,или апачи с конфигурацией типа кейпаливе, тут нужен специалист, доступ, и он разберётся что к чему, грамматика не причём =) да и отзывы го варят сами за себя =)
MaxSpareServers - 10, MaxClients - 150. Я не понимаю, почему из этого следует, что система не справляется - лишних процессов не будет, апачем запрос обрабатывается короткое время, так как nginx проксирует на него. Вывод - после нескольких событий, которые происходят периодически, процессы apache, которым хватало памяти, забирают себе лишнюю память, после чего ее хватать перестает. Один путь решения - перезапустить apache, другой - перезапускать отдельные его процессы, или, например, снимать kill'ом самые дорогие по памяти процессы.
keepalive и nginx - что Вы курите? :)
madoff:
Я могу сказать что параметр MaxRequestsPerChild имеет значение. Но не в TC ситуации он вряд-ли поможет, у него стоит nginx ограничитель серверы, да и макс клиент стоит смешной, хотя TC не написал какие параметры его системы, так-же нужно смотреть на кейпаливы, сколка реквестов, вопщем целая статья рисуется.
А при чем тут nginx? Он ограничивает количество одновременных запросов к apache (конечно, если так настроено), а внутрь apache он не лезет.
Почему-то Вы считаете, что PHP, apache и все библиотеки работают идеально и как написано в конфиге, а проблема в посещаемости и нагрузке. Я же не исключаю вариант с первой проблемой, и поэтому интересуюсь результатом установки MaxRequestsPerChild.
Кстати, интересный вопрос к ТС: память "размазывается" по процессам apache равномерно, или выделяется какой-то один процесс, съедающий ее всю?
SElinux - далеко не firewall, и там не только надо порты открывать. cPanel ставит все ПО сам, поэтому настройки вендора не подойдут для него (разве что - для стандартных сервисов переписать вендорские и придумать что-то для cPanel), либо разрешить все для этих сервисов, что вообще глупо.
Ввиду убогости* и отсутствия нормальной документации по SElinux, это никому не нужно.
* - возможно, он и не убог. Но в том виде, в котором оно идет сейчас, использовать и конфигурировать это практически не возможно. Говорю как человек, пытавшийся прожить 2 недели на десктопе с селинуксом) Вот было бы что-то подобное iptables, когда каждый сисколл прогоняется по списку правил.. цены бы не было. Но и работало бы долго.
Обычно нет, но он может это делать, если специально попросить.
Штатными средствами - нет; 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, на него можно будет делегировать домены.
да уж, ваши ответы содержательней, я наблюдаю, типа epel Отстой, alt Рулит. Я лучше буду
помогать чем блеск наводить на своих словах, тут видно кто чего стоит, мы же всё понимаем :) уважаемый Долгов :)
Ну, мои ответы будут получше, чем "Пешыти, рас биремься платна". А тот ответ являлся рекомендацией использовать nginx-0.8, который скоро станет stable вместо nginx-0.6, в который уже давно не бекпортят багфиксы и не добавляют функционал, данный в шутливой форме.
давайте Долгов будем реалистами вы советуете "MaxRequestsPerChild " это смешно рассчитывать на то что у него утечка памяти в библиотеках или хз ещё где, тут если кто и написал что то то, в плане макс клиент было более верное направление, но снова таки TC сказал что стоит у него NGINX значит у него уже всё оптимизированный.
Давайте. PHP изначально был рассчитан и писался под web и cgi, где процесс живет секунды, и сразу умирает. Поэтому, там классически есть места, где что-то не подчищается (конечно, это фиксится, и заметно нафиксено за последнее время), не возвращаются sbrk/malloc, и так далее. При использовании php-as-cgi это не возникает, при использовании mod_php или fastcgi - возникает. Кроме того, подключена куча модулей, в которых тоже может быть как-то накосячено. Не исключено, что у ТС в скриптах используется что-то странное, что и вызывает наружу этот баг.
что видно из следующего поста.
<IfModule mpm_prefork_module>
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 150
MaxRequestsPerChild 0
</IfModule>
У него уже всё по минимуму, не у желе вы Долгов это не видите, если уменьшение макс клиента не помогает значит у него система не справляется с нагрузкой,или апачи с конфигурацией типа кейпаливе, тут нужен специалист, доступ, и он разберётся что к чему, грамматика не причём =) да и отзывы го варят сами за себя =)
MaxSpareServers - 10, MaxClients - 150. Я не понимаю, почему из этого следует, что система не справляется - лишних процессов не будет, апачем запрос обрабатывается короткое время, так как nginx проксирует на него. Вывод - после нескольких событий, которые происходят периодически, процессы apache, которым хватало памяти, забирают себе лишнюю память, после чего ее хватать перестает. Один путь решения - перезапустить apache, другой - перезапускать отдельные его процессы, или, например, снимать kill'ом самые дорогие по памяти процессы.
keepalive и nginx - что Вы курите? :)
Я могу сказать что параметр MaxRequestsPerChild имеет значение. Но не в TC ситуации он вряд-ли поможет, у него стоит nginx ограничитель серверы, да и макс клиент стоит смешной, хотя TC не написал какие параметры его системы, так-же нужно смотреть на кейпаливы, сколка реквестов, вопщем целая статья рисуется.
А при чем тут nginx? Он ограничивает количество одновременных запросов к apache (конечно, если так настроено), а внутрь apache он не лезет.
Почему-то Вы считаете, что PHP, apache и все библиотеки работают идеально и как написано в конфиге, а проблема в посещаемости и нагрузке. Я же не исключаю вариант с первой проблемой, и поэтому интересуюсь результатом установки MaxRequestsPerChild.
Кстати, интересный вопрос к ТС: память "размазывается" по процессам apache равномерно, или выделяется какой-то один процесс, съедающий ее всю?
Сапа - это вообще зло. Вторая часть лишняя :)
madoff, на каждую тему достаточно одного спамно-рекламного поста, полного грамматических ошибок.
Установка MaxRequestsPerChild не помогла?
У меня дизаин открылся почти мгновенно, а страница генерировалась долго.
Какой у Вас сервер и какая у Вас CMS?
nginx - уже проше.
1) создаете
map $http_host $id
{
alias.ru 1;
...
}
2) Пишете
server
{
location /
{
proxy_pass http://localhost:8080/$uri?id=1&$args;
}
}
Где localhost:8080 - адрес apache, на который проксируете.
В конец proxy_pass может потребоваться дописать вопросительный знак, а может и не потребовааться.
SElinux - далеко не firewall, и там не только надо порты открывать. cPanel ставит все ПО сам, поэтому настройки вендора не подойдут для него (разве что - для стандартных сервисов переписать вендорские и придумать что-то для cPanel), либо разрешить все для этих сервисов, что вообще глупо.
Ввиду убогости* и отсутствия нормальной документации по SElinux, это никому не нужно.
* - возможно, он и не убог. Но в том виде, в котором оно идет сейчас, использовать и конфигурировать это практически не возможно. Говорю как человек, пытавшийся прожить 2 недели на десктопе с селинуксом) Вот было бы что-то подобное iptables, когда каждый сисколл прогоняется по списку правил.. цены бы не было. Но и работало бы долго.
в epel - старье.
centos.alt.ru - рулит!