Erro de E / S com PHP5-FPM, ptrace (PEEKDATA) falhou

Question

Eu tenho muitos desses:

[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 

E quando o php atinge o máximo de crianças (pelo menos eu presumo que seja o caso) ele pára "trabalhando" ... agora eu sei que posso aumentar max_children (atualmente definido como 9) mas há uma maneira de parar o php de "morrer" ?

Estou em um VPS com 1 núcleo e 512 MB de RAM (PHP5-FPM 5.4.4 + APC 3.1.10).

Depois de desabilitar o log lento, estou chegando agora:

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

Eu acho que não é normal que esses scripts sejam tão lentos .. Você sugere jogar com max_execution_time?

    

Answer 1

Parece que você tem request_slowlog_timeout ativado. Isso normalmente leva qualquer pedido por mais de N segundos, registra que ele estava demorando e registra um rastreio de pilha do script para que você possa ver o que estava demorando tanto.

No seu caso, o rastreamento de pilha (para determinar o que o script está fazendo) está falhando. Se você está ficando sem processos, é porque:

1. Após o php-fpm parar o processo para rastreá-lo, o processo não é retomado devido ao erro de rastreamento
2. O processo está sendo retomado, mas continua sendo executado para sempre.

Meu primeiro palpite seria desabilitar request_slowlog_timeout. Desde que não está funcionando direito, pode estar fazendo mais mal do que bem. Se isso não corrigir o problema de ficar sem processos, defina o php.ini max_execution_time como algo que irá matar o script com certeza.

    

Answer 2

Uma explicação mais válida para o ptrace (PEEKDATA) falhou parece ser esta -

... the worker is free to go when the master is determining slow execution. When stopping to be traced, it may have completed that execution and is in any stage serving another request, so the tracer gets the chance of failure or worse, dumping out the stack of an irrelevant execution.

de FPM Slowlog é uma droga que explica toda a confusão com muito mais detalhes .