Почему зависает apache2?

Question

[zdravnik]

Стоит nginx/1.8.0 и httpd 2.2.15 на CentOS 6.7
mpm конфиг следующий:

ServerLimit 500
StartServers 4
MinSpareServers 4
MaxSpareServers 8
MaxClients 500
KeepAlive On
KeepAliveTimeout 5
MaxRequestsPerChild 3000
ListenBacklog 512

В sysctl.conf задействованы следующие опции:

vm.overcommit_ratio = 100
vm.overcommit_memory = 2

Но я не уверен что эти опции влияют на проблему.

После имитации высокой нагрузки либо ддоса, с помощью siege и последующей остановки нагрузки, апач частенько подвисает, strace говорит следующее:

[pid 63565] <... restart_syscall resumed> ) = 0
[pid 63565] clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f9421beeab0) = -1 ENOMEM (Cannot allocate memory)
[pid 63565] write(2, "[Thu Jan 28 12:58:31 2016] [erro"..., 96) = 96
[pid 63565] rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
[pid 63565] rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
[pid 63565] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid 63565] nanosleep({10, 0},
[pid 63565] <... nanosleep resumed> 0x7ffe6a49de20) = 0
[pid 63565] clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f9421beeab0) = -1 ENOMEM (Cannot allocate memory)
[pid 63565] write(2, "[Thu Jan 28 12:58:41 2016] [erro"..., 96) = 96
[pid 63565] rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
[pid 63565] rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
[pid 63565] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid 63565] nanosleep({10, 0},

Бывает что подвисает не на долго, на 1-2 минуты например, а затем просыпается и начинает убивать своих детей и нормально работать, а иногда подвисания бывают и более долгие, например 20 минут (более ждать не мог, рестартанул железку). Но бывает и так что не зависает. Если в момент подвисания апача, попытаться рестартануть апач, то мастер процесс умрет и больше не запуститься потому что все дети остаются висеть в системе.
В общем бьюсь уже неделю, не могу понять в чем проблема.
Есть идеи?

Answer 1

[Андрей]

а нужен ли вообще апач?

Answer 2

[zdravnik]

Апач нужен однозначно.

Answer 3

[synapse_people]

Офигенные советы..
Попробуй поставить апач 2.4. Кстати, включен ли своп в системе?

Comments

[zdravnik]

В соответствии с политикой партии, апач можно юзать только 2.2

Answer 4

[neol]

MaxClients 500

Вы на что вообще надеялись, когда выставляли такое значение?
Если у вас приложение, СУБД, реверс-прокси и прочее на одном сервере, то MaxClients обычно имеет смысл ставить в 2-8 раз больше количества ядер (зависит от приложения), иначе сервер превращается в тыкву.

Comments

[zdravnik]

Я такое значение выставлял исходя из:
1)surniaulula.com/2012/11/09/check-apache-httpd-mpm-... и cloudinservice.com/tune-apache-performance-using-m...
2)опираясь но официальные докс апача, куча прочитанной инфы на стакоферфлоу и прочих ресурсов, а так же на свою голову.

ЧТо касается других ваших предположений, то сообщу что на данном сервере крутится исключительно апач и нгинкс, все остальное вынесено за пределы обсуждаемого сервера.

Мнение про некоторую связь между значением MaxClients и количеством ядер весьма интересно. Пытался найти инфу об этой зависимости когда читал вышеперечисленные доки, но ничего путного не нашел. Буду рад если сможете предоставить что-то полезное на эту тему.

Ну и к слову сказать по идеи значение MaxClients можно выставить хоть 100500, потому что тюнинг sysctl
vm.overcommit_ratio = 100
vm.overcommit_memory = 2
Не даст апачу нафоркать процессов больше чем есть памяти на сервере.

P.S. Не исключено конечно что я могу и ошибаться в своих высказываниях.

[zdravnik]

neol

[neol]

zdravnik: Вам быстрее будет попробовать постепенно уменьшать MaxClients, прогоняя тесты, чем ждать когда я нагуглю дельные ссылки по этому поводу.

Например, вот: serverfault.com/questions/58097/optimal-values-for...

У вас в логе английским языком написано, что apache не может форкнуться из-за нехватки памяти, так что в любом случае MaxClients надо уменьшать.

Мнение про некоторую связь между значением MaxClients и количеством ядер весьма интересно. Пытался найти инфу об этой зависимости когда читал вышеперечисленные доки, но ничего путного не нашел. Буду рад если сможете предоставить что-то полезное на эту тему.

Чёткой взаимосвязи тут нет. 2-8 - это очень условный диапазон из собственного опыта, с которого стоит начинать подбирать наиболее подходящее значение для вашего случая. Если ваше приложение большую часть времени ждет ответа от СУБД или какого-то стороннего API, то ориентироваться можно только по потребляемой памяти.

[zdravnik]

У меня просто ядер много, и судя по статистики они не так сильно напрягаются как память.
Постепенно уменьшать MaxClients для меня не вариант, потому что у меня не один не два и не 10 серверов, соответственно сидеть под каждый подбирать значение затея мало перспективная. Нужны какие-то более универсальные методы. Да и апачи форки в рамках одного приложения могут занимать разное кол-во памяти, могут запустить пару тройку форком тяжелах, и не спасет MaxClients , придет оом киллер и конец. Именно для этого я и подтюнил sysctl, чтобы апач не мог занимать больше памяти чем ему может быть выделенно, лучше пускай он зафейлит некий процент запросов в момент высокой нагрузки в связи с невозможностью зафоркать , чем повесит наглухо сервак.

Мне вот еще что интересно, даю нагрузку, затем нагрузку останавливаю, при этом в сторону приложения не идет ВООБЩЕ никаких запросов, но strace показывает что апач все еще продолжает обрабатывать в течении какого-то времни какие-то запросы. Думал что это нгинкс ему доотправляет то что наполучал, но если отключить нгинкс в этот момент, то апач все равно обраюатывает какие-то запросы, как-будто из какой то очереди. Пробовал ставить ListenBacklog 1, картина та же

[zdravnik]

neol

[neol]

zdravnik: Ну либо вы считаете сколько памяти нужно вашему приложению в худшем случае, либо надеетесь на авось. Если главному процессу нужна память, а получить её он не может, то может произойти любая хрень с непредсказуемым результатом.

Лично я как-то ограничивал потребление памяти через ulimit в скрипте инициализации apache:

ulimit -v X

Значение выставлялось с небольшим запасом по данным системы мониторинга о максимальном потреблении памяти при нормальной работе приложения. MaxClients соответственно выставлен в такое значение, что X * MaxClients < объёма памяти.

vm.overcommit_memory = 2 при этом нафиг не нужно и такое ограничение вроде как не должно оказывать влияния на работу главного процесса apache. Но это всё-равно костыль и использовал я его только пока не поправили утечку в коде приложения.

Про запросы есть мысль только про internal dummy connection. Но любые запросы должны отражаться в логах, если эти запросу действительно были, так что можно посмотреть.

PS мне итак приходят уведомления о каждом комментарии к моему ответу, явно указывать, что комментарий адресован мне, не обязательно.

[zdravnik]

Ну так главный процесс занял определенное кол-во памяти при старте так и работает. И отнимать у него эту память при использовании vm.overcommit_memory = 2 не будет. А значит должен он себя адекватно вести.