PHP Fatal error: Maximum execution time of 30 seconds exceeded in Unknown on line 0

Question

[L0NGMAN]

В логах появляется такие записи «PHP Fatal error: Maximum execution time of 30 seconds exceeded in Unknown on line 0» и сервер зависает, по ssh/ftp не заходит но на пинг отвечает. Сталкивалса ли кто нибудь с таким чудам? Сервер Apache/2.2.3 (CentOS), PHP 5.3.10

Answer 1

[Ivan Shalganov]

Могу предположить, что у вас скрипт впадает в рекурсию, залипает, апач начинает феерически форкаться что бы удовлетворить запросы, новые процессы так же залипают, система эпохально теряет ресуры (память и процессорное время), многое забивается в своп, остальные процессы становятся не дееспособными такие как ssh, ftp из-за отсутвия ресурсов. апач так же встает так как fork перестаёт работать. После некоторого времени скрипт убивается апач-форком по max_execution_time, ресурсы возвращается, солнце становится ярче, небо голубее, ssh быстрее. Как-то так. Итого: очень тяжелый скрипт детектед.

Comments

[L0NGMAN]

Как можно найти код где происходит все это? Как локализовать ошибку? Проект очень большой а код писал не я…

[Vitali Borovik]

Ну вы маньяк, если еще дописать как пакеты летают можно написать книгу про работу веб сервера в художественном стиле.
Если скрипт раньше работал то рекурсия и бесконечные циклы отпадают. Остается только то, что данных стало больше и в 30 секунд они не успевают обрабатываться. Выход — упростить/разделить.

[Vitali Borovik]

Сложно сказать не зная проект, как вариант поставить exit() перед предполагаемым сложным куском (научный метод). Потом после, посмотреть результат, но нужно учесть что бы в нем не было инклюдов).
Так же посмотрите в Ваш логер, может там допущена ошибка при выводе линии, это бы здорово Вам помогло.

[Ivan Shalganov]

Если ищите решение «в лоб», то что бы узнать что происходит, рекомендую поставить xDebug на сервер (да простят меня адепты hightload), в ini:
xdebug.profiler_enable = 1
xdebug.profiler_output_dir = /tmp
xdebug.profiler_output_name = cachegrind.out.%t

Поставить у себя KCacheGrind или WinCacheGrind, загрузить туда cachegrind.out.* с сервера и… лицезреть полный отчет кто, что, куда и сколько раз. НО, пока xDebug будет агрегировать cachegrind.out.* производительность упадёт в сотни раз. Может стать ещё хуже, так что проделывайте это во время минимальной нагрузке, либо на тестовом стенде.

[Ivan Shalganov]

Ещё ещё одно тёмное колдунство, не постижимое доселе обычными PHP-магами, но на много эффективнее — DTrace (http://www.sunhelp.ru/archives/161-DTrace_iwem_prichinu_povyshennoj_zagruzki_CPU.html). Только истинные ситхи вкурсе как подружить его с апачем.
Так же забыл упомянуть что с xDebug на cachegrind.out.* будут выделятся тонны килобайт диска. Дисковое пространство будет течь, как призывник с энурезом. GL!

Answer 2

[cat_crash]

Дополню предыдущий пост, уважаемого Aco
Судя по симптомом действительно системе жутко не хватает ресурсов.
— Далеко не факт что если раньше работал то нет рекурсии. Ошибка в логике + неверные данные = бесконечная рекурсия.
Что могу посоветовать:
— Поиграйтесь с memory_limit. Он может помочь найти «слабое звено» т.к. рекурсия обычно черевата съеданием ресурсов системы
Ну и конечно жестокое порно дебаг ночами на тестовом энваирменте. Только так вы сможите разобраться в логике чужого кода и найти bottleneck

Answer 3

[step307]

Посмотрите еще access log, что предшествовало падению, какие запросы. Возможно это натолкнет на какую-нибудь мысль.

Важно еще понимать периодичность возникновения проблемы. Связано это с количество юзеров (соотв. нехваткой ресурса) или с заходом поискового робота или с редким но «метким» вызовом какойто тяжелой функции (по переколбасу кэша, импорту большого объема данных и т.д.)

Answer 4

[Виталий Желтяков]

Попробуйте set_time_limit(0);. Если не поможет, то это может быть бесконечная рекурсия.

Answer 5

[L0NGMAN]

Спасибо всем большое, пойду дебажить. Поставлю xDebug

Answer 6

[egorinsk]

Если вы используете apache, то первым делом смотрите вывод top под нагрузкой, вторым — поставьте mod_status и проверьте, какие запросы висят. Тогда уже можно смотреть почему. Такде, можно логгировать время выполнения запросов (апач это позволяет)

Answer 7

[WebCraft]

«Unknown on line 0» скорее всего указывает на то, что скрипт закодирован зендом\ионкубом или похожим образом. Посмотрите сперва в сам скрипт (его имя выводится в журнал, разрешите запись в error_log).

Comments

[L0NGMAN]

Нет там никакого зенда/ионкуба. А текст ошибки я привел как раз из error_log. Я переписал сомнительные места в проекте и проблема исчезла.