"Залипает" php-fpm?

Question

[GarretUA]

Добрый день.



Столкнулся со странной проблемой.



Дано: сервер на Amazon EC2(инстанс m1.large: ~ 2x2.3GHz CPU, 7.5 Gb RAM), на нем Debian 6.0 и крутится nginx + php-fpm 5.3.9(через юникс сокеты). Выполнены настройки под хайлоад как со стороны nginx/php так и со стороны системы. Нагрузка небольшая: 300+k хитов, запросы идут в основном на простой функционал(это баннерная сеть), база на отдельностоящем RDS работает без проблем. Прикручена система мониторинга от сервиса newrelic.com



PHP-FPM: работает в два пула. Второй с идентичным конфигом.

listen = /tmp/php-fpm.sock



listen.backlog = -1



pm = dynamic

pm.max_children = 100

pm.start_servers = 30

pm.min_spare_servers = 20

pm.max_spare_servers = 50

pm.max_requests = 100

Из экстеншенов только apc добавлено.



Проблема: через некоторое время(например немного позже пика активности) сервер перестает отвечать, зайти по ssh невозможно, старые коннекты отваливаются. Amazon CloudWatch показывает использование CPU на одном уровне(при разных настройках php-fpm было по разному, то 100%, то 50%, 25%).

Мониторинг от newrelic вообще отваливается и у них на сайте не отображаются никакие данные(м.б. какие то проблемы с сетью возникают).



Единственное что у меня есть это информация из /var/log/messages указывающая на как я понимаю проблему с памятью(спасибо Амазону что не додумались в своем мониторинге показывать загрузку оперативы).



Но остаются вопросы: почему не хватает 7.5 Гб, когда в пике по стате было максимум 3 Гб использовано(memory leak какой то?); почему зависает при этом и не попускается до парочки ребутов?



Админ из меня конечно не очень, может подскажите что можно помониторить, какие конфиги покрутить что бы решить данную проблему?



Заранее спасибо.



Вот график CloudWatch:





Вот /var/log/messages:

kernel: [235830.623812] hrtimer: interrupt took 46615898 ns

kernel: [236936.599597] php-fpm invoked oom-killer: gfp_mask=0x280da, order=0, oom_adj=0

kernel: [236936.599614] php-fpm cpuset=/ mems_allowed=0

kernel: [236936.599620] Pid: 25206, comm: php-fpm Not tainted 2.6.32-5-xen-amd64 #1

kernel: [236936.599625] Call Trace:

kernel: [236936.599637] []? oom_kill_process+0x7f/0x23f

kernel: [236936.599644] []? __out_of_memory+0x12a/0x141

kernel: [236936.599650] []? out_of_memory+0x140/0x172

kernel: [236936.599657] []? __alloc_pages_nodemask+0x4e5/0x5f5

kernel: [236936.599664] []? xen_mc_flush+0x159/0x185

kernel: [236936.599671] []? handle_mm_fault+0x27a/0x80f

kernel: [236936.599678] []? do_brk+0x227/0x301

kernel: [236936.599685] []? do_page_fault+0x2e0/0x2fc

kernel: [236936.599693] []? page_fault+0x25/0x30

Answer 1

[Влад Животнев]

Память заканчивается, приходит OOM и убивает процессы.

Comments

[Влад Животнев]

Система не 32х битная, случайно?

[GarretUA]

Нет, 64х битная.

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

Answer 2

[ValdikSS]

Тут кто-то в QA уже спрашивал, почему php 5.3 жрет больше оперативки, чем 5.2. Пока, как временный вариант, можете сделать в php-fpm респавн через сколько-то реквестов.
pm.max_requests = 500

Comments

[GarretUA]

У меня уже стоит pm.max_requests = 100 на всякий случай. Попробую наверное пересобрать пых с минимальным количеством модулей.

Answer 3

[GarretUA]

Я свою проблему решил, но точного рецепта не скажу. И в потолок памяти все таки процессы упирались, правда это происходило так резко что мониторинг ничего не успевал показать.

Был комплекс всяких изменений сделан:
— php сделан с минимальным набором модулей
— убрал new-relic экстеншен для мониторинга работы пхп(есть подозрения что от него могло залипать)
— субд переехала с Amazon RDS на обычный EC2, что позволило более тонко настроить мускуль
— был выявлен запрос который мог тормозить работу из за большого объема передаваемых данных(вариант с бизнес-логикой в пхп) или нагружать базу(бизнес-логика на субд) и соответственно немного переделана архитектура что бы избежать этих проблем

Так что по большому счету это проблема со стороны кода скорее, а со стороны сервера немного странное поведение при возникновении этой проблемы.

Answer 4

[rakot]

Поставьте в крон скрипт, который будет собирать логи по расходу оперативки, написать его не займет более получаса.
Кстати PHP сами собирали или из dotdeb?

Comments

[GarretUA]

Собирал сам.

[rakot]

Может попробовать dotdeb?

[GarretUA]

Не думаю что я мог что то не так собрать. Но если не найду решения то и с дотдэба установить попробую :)

Answer 5

[silverwind]

Нет решения?
Схожая проблема, схожие настройки и ПО, только сервер физ. свой, 8гб и интел квад-коре 2.8ггц.

Comments

[GarretUA]

Я свою проблему решил, но точного рецепта не скажу. И в потолок памяти все таки процессы упирались, правда это происходило так резко что мониторинг ничего не успевал показать.

Был комплекс всяких изменений сделан:
— php сделан с минимальным набором модулей
— убрал new-relic экстеншен для мониторинга работы пхп(есть подозрения что от него могло залипать)
— субд переехала с Amazon RDS на обычный EC2, что позволило более тонко настроить мускуль
— был выявлен запрос который мог тормозить работу из за большого объема передаваемых данных(вариант с бизнес-логикой в пхп) или нагружать базу(бизнес-логика на субд) и соответственно немного переделана архитектура что бы избежать этих проблем

Так что по большому счету это проблема со стороны кода скорее, а со стороны сервера немного странное поведение при возникновении этой проблемы.