Detailed explanation of php-fpm startup parameter configuration

You need to agree on several directories

#Test php-fpm configuration
/usr/local/php/sbin/php-fpm -t
/usr/local/php/sbin/php-fpm -c /usr/local/php/etc /php.ini -y /usr/local/php/etc/php-fpm.conf -t

#Start php-fpm
/usr/local/php/sbin/php-fpm
/usr/local/php/ sbin/php-fpm -c /usr/local/php/etc/php.ini -y /usr/local/php/etc/php-fpm.conf

#Close php-fpm
kill -int `cat /usr /local/php/var/run/php-fpm.pid`

#Restart php-fpm
kill -usr2 `cat /usr/local/php/var/run/php-fpm.pid`

Second, detailed explanation of important parameters of php-fpm.conf

$ctx = stream_context_create(array(
 'http' => array(
 'timeout' => 10 //Set a timeout in seconds
 )
));

file_get_contents( $str, 0, $ctx);

2, improper configuration of the max_requests parameter may cause intermittent 502 errors: pm.max_requests = 1000 Sets the number of requests served before each child process is reborn. Useful for third-party modules that may have memory leaks. If set to '0', requests are always accepted. Equivalent to the php_fcgi_max_requests environment variable. Default: 0. The meaning of this configuration is that when the number of requests processed by a php-cgi process accumulates to 500, the process will be automatically restarted.

But why restart the process?

Generally in projects, we will use some third-party libraries of PHP to some extent. These third-party libraries often have memory leak problems. If the php-cgi process is not restarted regularly, the memory usage will inevitably increase. Therefore, php-fpm, as the manager of php-cgi, provides such a monitoring function to restart the php-cgi process that has requested a specified number of times to ensure that the memory usage does not increase.

It is precisely because of this mechanism that 502 errors are often caused in high-concurrency sites. I guess the reason is that php-fpm does not handle the request queue from nginx well. However, I am still using php 5.3.2. I don’t know if this problem still exists in php 5.3.3.

Our current solution is to set this value as large as possible to reduce the number of re-spawns of php-cgi as much as possible, and at the same time improve the overall performance. In our own actual production environment, we found that the memory leak was not obvious, so we set this value very large (204800). Everyone should set this value according to their actual situation and cannot blindly increase it.

Having said that, the purpose of this mechanism is only to ensure that php-cgi does not occupy excessive memory. Why not deal with it by detecting memory? I very much agree with what Gao Chunhui said, restarting the php-cgi process by setting the peak internal usage of the process would be a better solution.

3, php-fpm’s slow log, debug and exception troubleshooting tool: request_slowlog_timeout sets a timeout parameter, and slowlog sets the storage location of the slow log. tail -f /var/log/www.slow.log The above command can see the php process that is executing too slowly.

You can see the common problems of excessive network reading and slow mysql query. If you follow the prompt information to troubleshoot the problem, you will have a clear direction.