Problems caused by Linux nginx php Optimization

A Nginx + PHP project encountered a performance problem a few days ago, so I planned to train my hands because the code was not written by myself, so we decided to start from the system level to see if we could make some rough line optimization. First, I found that the Backlog settings of the service are too small. You can use the ss Command to query Send-Q to confirm: shellss-lnRecv-QSend-QLoc

A Nginx + PHP project encountered a performance problem a few days ago, so I planned to train my hands because the code was not written by myself, so we decided to start from the system level to see if we could make some rough line optimization. First, I found that the Backlog settings of the service are too small. You can use the ss Command to query Send-Q to confirm that shell ss-lnRecv-Q Send-Q Loc

A Nginx + PHP project encountered a performance problem a few days ago, so I planned to train my hands because the code was not written by myself, so we decided to start from the system level to see if we could make some rough line optimization.

First, I found that the Backlog settings of the service are too small. You can use the ss Command to query Send-Q to confirm that:

shell> ss -lnRecv-Q Send-Q    Local Address:Port      Peer Address:Port0      511                   *:80                   *:*0      128           127.0.0.1:9000                 *:*

Obviously, Nginx's Backlog is 511; PHP's Backlog is 128, which easily becomes a bottleneck in high concurrency. For more information about TCP queues, read 「? Some Questions about TCP queue ". If you are interested, can you take a look at it in Linux? Full connection and? How is the length of a semi-join queue calculated.

Second, I found that the number of processes in the service is too small. The number of Nginx processes is good to say? Worker_processes command control, set according to the number of CPUs, if the version is enough, you can directly set to auto .? PHP does not have a fixed answer to the appropriate number of processes. If the memory is sufficient, I usually select static mode and set 1024 processes, of course, we cannot unilaterally think that the more processes the better, or the scheduling will become a problem.

I suggest you read the following information about the balance between the number of PHP processes:

• Some misunderstandings about max_chin.pdf of php-fpm
• Shocould PHP Workers Always Equal Number Of CPUs

According to the above analysis, everything went very smoothly during the implementation of the test environment, but I was completely scared during the formal implementation of the environment: first, optimize PHP and everything went fine; then we optimized Nginx. As a result, the service went down, and the Nginx optimization was rolled back. The service still failed. But let's go! restart the server, Nima!

In a twinkling of an eye, I experienced an inexplicable big sorrow and happiness, which is really unbearable. Fortunately, everything went normal after I restarted the server. I can easily find out the cause of the problem, the error log contains the following clues:

Setuid (99) failed (11: Resource temporarily unavailable)

There was a shortage of resources! Confirm the user:

shell> grep -w 99 /etc/passwdnobody:x:99:99:Nobody:/:/sbin/nologin

The sub-processes of Nginx and PHP are started by the nobody user. It seems that the problem is located here. Why is the test environment normal and the formal environment abnormal? The original difference appeared in the operating system version: although the operating system is CentOS, the test environment version is 5.5, and the official environment version is 6.2, the most terrible thing is that the new operating system has a configuration file that limits the number of user processes. The default setting is 1024:

shell> cat /etc/security/limits.d/90-nproc.conf# Default limit for number of user's processes to prevent# accidental fork bombs.# See rhbz #432903 for reasoning.*          soft    nproc     1024

That is to say, a nobody user can start up to 1024 processes. In this case, due to the large number of started processes, the PHP optimized first suddenly spent all the resource quotas. When Nginx was optimized, failure could not be avoided.

But why does everything look normal after I restart the server? This is caused by the startup sequence:

shell> ls /etc/rc3.d/ | grep -E 'nginx|php'S55nginxS84php-fpm

That is to say, after the server is restarted, Nginx is started before PHP. due to the small number of Nginx processes, Nginx is started successfully. When PHP is started, the threshold is still triggered, however, most processes can be successfully started, and only a small number of processes fail to be started. Therefore, we think the process is successful.

If you are still confused about the cases caused by this optimization, can you continue to read them? Ulimit restrictions: nproc problems.

Original article address: problems caused by linux nginx optimization php. Thank you for sharing it with me.