OSSHelp

Рейтинг
36
Регистрация
12.07.2012
pupseg:
В данном случае они привыкли ковырять простейшие задачи. И в текущем вопросе попросят или других денег, чем у них на сайте в прайсе, или ниасилят выше написанное мной, собственно как и любая компания, предоставляющая услуги массового администрирования. Хотя, не хочу наговаривать. Кто знает....

Ну это и выглядит, как "наговаривать". Не стану рассказывать, что мол всеведущие гуру и решаем любые проблемы дистанционно и телепатически. Но некоторый опыт все же есть, в том диагностика "подземного стука". Как и не вижу смысла рассказывать "решаем проблемы любой сложности за плошку риса". Все зависит от затраченных усилий. Сами, думаю, прекрасно понимаете.

pupseg:

Перезагружать FPM по крону и всякие drop_caches - для школьников от вредных советов. Подобное прошу не советовать. Зуб нужно лечить, а не пить обезболивающие.
Приветствуется критика, вопросы, что я не учел, что я пропустил?

Я наверное сейчас буду нещадно капитанить и тыкать пальцем в небо, но все же.

1) Почему Nginx считает пулы "bad gateway" удалось прояснить? FPM-пул вообще коннект не принимает, принимает и сразу сбрасывает? Хотя бы для своего адреса включите debug_connection и потыкайте в код в момент залипания. В debug'е из error лога возможно что-то полезное будет. Отсюда уже N возможных вариантов.

2) Что в момент 502й с master'ом и child'ами? Продолжают шевелиться (и жрать проц), висят в холостую или вообще залипли? В условиях высокого RPS проблематично, но иногда все же удается что-то полезное вытащить, зацепившись strace/ltrace на какой-то из child'ов.

3) Child'ы падают в момент 502й или нет? Есть в dmesg про SIGSEGV и иже с ними? Если да, то включить coredump и попробовать с gdb заглянуть под капот. Так можно найти кто именно течет (может какой из PECL модулей).

Ну и эксперимента ради переключите один из сервер с ondemand на dynamic. Так возможно будет чуть проще зацепиться к кому-то из child'ов и посмотреть что он там творит.

Плюс никто не мешает поднять рядом еще один пул один в один на другом порту и в nginx в upstream добавить его как backup. Так вы получите возможность спокойно тыкать палочкой в умерший FPM-пул, когда траф будет молотить еще пока рабочий "запасной" пул.

Надеюсь не зря влез в топик и хоть что-то из этого будет полезно :)

PS: Кстати, третий сценарий хоть и выглядит "мифическим", но мы видели ситуации, когда fpm или mod_php5 спустя некоторое время работы начинает крэшиться только на части сайтов. Причем остальные сайты и тестовые скрипты в этот же момент работают прекрасно. Раскопали, что крыло один из PECL модулей, но апдейтов для этой ветки PHP не было. Поэтому разработчики клиента решили в качестве workaround поменять проблематичный кусок кода. Да, некошерно и коряво, но бизнес решил свою "проблему".