PHP project, CPU burst problem lookup

Background:

A few days ago through the WordPress on-line an application (pre-background deployment separation, backstage walk intranet internal use, the foreground did the whole station cache external use).

Today's access to background app discovery starts at 504, all 504 after a while.

Solution:

Login container found in container nginx log all 499.

The top command found that the PHP-FPM occupied a CPU burst.

Netstat-anp|grep ' php-fpm port number ' found that all php-fpm states are SYN_RECV (after the server has been passively opened, the client's SYN is received and the ACK State is sent)

All php-fpm states are syn_recv, causing the number of queues that control synqueue to be full and all new requests to be rejected directly.

Immediately through the Strace command to trace the PID, found that has been in the loop to perform some functions such as Gettimeofday

Online find data said if the open Xdebug extension will cause such a situation, through php-m found sure to use the Xdebug, close this extension, restart PHP-FPM.

It was observed that the CPU utilization was steady, the PHP-FPM state was normal and everything was OK.

Summarize:

Do not open the Xdebug extension on the line, why Xdebug will cause this kind of problem, not in-depth understanding, but xdebug performance is not suitable for online use, we recommend the use of php_trace extension instead

The PHP code execution process is detected through php_trace, and you can view the previously written article on how to use Php_trace. (Php_trace is 360 open source tools, powerful, tested on-line only about a few percent of performance)

Open PHP-FPM Status monitoring, it is better to increase the alarm mechanism, has been found in time and obtain the cause of the problem.

Explanation:

Here it is necessary to explain why the TCP connection backlog in the queue, to understand this problem, you need to understand the Linux on the TCP three handshake some of the specific implementation.

We know that on the server side, listening on a port, call Socket,bind Last Call listen:

int listen(intsockfd, int backlog);

The second parameter of the listen is called the backlog, which sets the size of the connection queue. The actual Linux maintenance two queues, one is after receiving the SYN, at this time did not complete three times handshake, is in the semi-connected state, the storage to synqueue (our problem is to happen here),

The other is three times after the handshake is completed, the connection is successfully established, stored in the Acceptqueue, waiting for the application to call accept to consume the queue. The backlog here is used to set the size of the accept queue (the legacy kernel used to set the SYN queue, please man listen for details).

TCP Transport and system calls are actually an asynchronous process through which the system stores the latest TCP state or data. That is, the TCP three handshake is done by the kernel, regardless of whether the application layer calls accept, the kernel will complete the three-handshake socket into the Acceptqueue, the application calls accept, the connection from the accept queue. Then, if the backlog is very large, and I do not call accept in time to consume the queue, then the connection is backlog in the accept queue.

Similarly, after three handshake finishes, the client can send the data, the data is received by the kernel and stored in buffer in TCP, and the application (PHP) may not have called accept yet.

Finally thanked once the interviewer, because before asked how to find the online CPU explosion problem, and then found the next basic information, did not expect this time to use.

PHP project, CPU burst problem lookup