一. Google能告訴我們的

It appears you have request_slowlog_timeout enabled. This normally takes any request longer than N seconds, logs that it was taking a long time, then logs a stack trace of the script so you can see what it was doing that was taking so long.

In your case, the stack trace (to determine what the script is doing) is failing. If you're running out of processes, it is because either:

• After php-fpm stops the process to trace it, the process fails to resume because of the error tracing it
• The process is resuming but continues to run forever.

My first guess would be to disable request_slowlog_timeout. Since it's not working right, it may be doing more harm than good. If this doesn't fix the issue of running out of processes, then set the php.ini max_execution_time to something that will kill the script for sure.

ref: http://serverfault.com/questions/406532/i-o-error-with-php5-fpm-ptracepeekdata-failed

二. 源碼能告訴我們的

下面是打印堆棧信息的核心函數(shù)

/****************************************
source: https://launchpad.net/php-fpm
filename: fpm/fpm_trace_ptrace.c
*****************************************/

int fpm_trace_get_long(long addr, long *data)
{
        errno = 0;

        /*
        Reads  a word at the location addr in the child’s memory, 
        returning the word as the result of the ptrace() call
        */
        *data = ptrace(PTRACE_PEEKDATA, traced_pid, (void *) addr, 0);

        if (errno) {
                zlog(ZLOG_STUFF, ZLOG_SYSERROR, "ptrace(PEEKDATA) failed");
                return -1;
        }

        return 0;
}

當獲取被跟蹤進程的運行數(shù)據(jù)出錯時，就會打印錯誤信息。這種錯誤信息應該是無害的。

三. 擴展

ptrace系統(tǒng)函數(shù)。

ptrace提供了一種使父進程得以監(jiān)視和控制其它進程的方式，它還能夠改變子進程中的寄存器和內核映像，因而可以實現(xiàn)斷點調試和系統(tǒng)調用的跟蹤。