У меня таких много:
[NOTICE] child 19214 stopped for tracing
[NOTICE] about to trace 19214
[ERROR] ptrace(PEEKDATA) failed: Input/output error (5)
[NOTICE] finished trace of 19214
[WARNING] [pool www] child 19208, script 'blahblah.php' executing too slow (30.041419 sec), logging
[NOTICE] child 19208 stopped for tracing
[NOTICE] about to trace 19208
[ERROR] ptrace(PEEKDATA) failed: Input/output error (5)
[NOTICE] finished trace of 19208
[WARNING] [pool www] child 19218, script 'blahblah.php' executing too slow (30.035029 sec), logging
И когда php достигает максимального количества детей (по крайней мере, я предполагаю, что это так), он перестает "работать" ... теперь я знаю, что могу увеличить max_children (в настоящее время установлено значение 9), но есть способ остановить php от "смерти"?
Я использую VPS с 1 ядром и 512 МБ ОЗУ (PHP5-FPM 5.4.4 + APC 3.1.10).
После отключения медленного журнала я получаю:
WARNING: [pool www] child 1684 exited on signal 15 (SIGTERM) after 77.802376 seconds from start
NOTICE: [pool www] child 1694 started
WARNING: [pool www] child 1377, script 'blahblah.php' (request: "GET /blahblah.php") execution timed out (38.291440 sec), terminating
WARNING: [pool www] child 1377 exited on signal 15 (SIGTERM) after 2750.295279 seconds from start
NOTICE: [pool www] child 1696 started
WARNING: [pool www] child 1722, script 'blahblah.php' (request: "POST /blahblah.php") execution timed out (39.653910 sec), terminating
WARNING: [pool www] child 1722 exited on signal 15 (SIGTERM) after 793.953090 seconds from start
Я считаю ненормальным, что эти скрипты такие медленные .. Вы предлагаете поиграть с max_execution_time?
Похоже, у вас есть request_slowlog_timeout включен. Обычно это занимает любой запрос дольше N секунд, регистрирует, что он занимал много времени, затем записывает трассировку стека скрипта, чтобы вы могли видеть, что он делал, что занимало так много времени.
В вашем случае трассировка стека (чтобы определить, что делает скрипт) не работает. Если у вас заканчиваются процессы, это происходит по одной из следующих причин:
Моей первой догадкой было бы отключить request_slowlog_timeout. Поскольку он работает неправильно, он может принести больше вреда, чем пользы. Если это не решит проблему нехватки процессов, установите php.ini max_execution_time к чему-то, что наверняка убьет сценарий.
Более верное объяснение ptrace (PEEKDATA) не удалось кажется это -
... рабочий может уйти, когда мастер определяет медленное выполнение. При остановке для трассировки он может завершить это выполнение и находится на любой стадии обслуживания другого запроса, поэтому трассировщик получает шанс сбоя или, что еще хуже, сброса стека несущественного выполнения.
из FPM Slowlog - отстой что объясняет всю неразбериху гораздо более подробно.