/usr/local/php/sbin/php-fpm
/usr/local/php/etc/php-fpm.conf
/usr/local/php/etc/php.ini
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 |
|
1,Resource problems caused by request_terminate_timeout
If the value of request_terminate_timeout is set to 0 or too long , may cause resource problems with file_get_contents.
If the remote resource requested by file_get_contents responds too slowly, file_get_contents will always be stuck there without timing out. We know that max_execution_time in php.ini can set the maximum execution time of PHP scripts, but in php-cgi (php-fpm), this parameter will not take effect. What can really control the maximum execution time of PHP scripts is the request_terminate_timeout parameter in the php-fpm.conf configuration file.
The default value of request_terminate_timeout is 0 seconds, which means that the PHP script will continue to execute. In this way, when all php-cgi processes are stuck in file_get_contents() Function, this Nginx+PHP WebServer can no longer process new PHP requests, and Nginx will return "502 Bad Gateway" to the user. ". Modifying this parameter is necessary to set the maximum execution time of a PHP script, but it only treats the symptoms rather than the root cause. For example, if it is changed to 30s, if file_get_contents() is slow to obtain web page content, this means that 150 php-cgi processes can only handle 5 requests per second, and it is also difficult for WebServer to avoid "502 Bad Gateway".
The solution is to set request_terminate_timeout to 10s or a reasonable value, or add a timeout parameter to file_get_contents.
1 2 3 4 5 6 7 |
|
2, Improper configuration of the max_requests parameter may cause intermittent 502 errors:
1 |
|
Set the number of requests served before each child process is reborn. For the first time that there may be a memory leak It is very useful for third-party modules. If set to '0', requests will always be accepted. Equivalent to the PHP_FCGI_MAX_REQUESTS environment variable. Default value: 0.
This configuration means that when a PHP-CGI process handles a request After the number accumulates to 500, the process will be automatically restarted.
But why do we need to 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, it will inevitably cause continuous memory usage. 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 highly concurrent sites. I guess the reason is that PHP-FPM does not handle the request queue coming 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 times PHP-CGI re-SPAWNs as much as possible, and at the same time improve 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 intrinsic usage of the process would be a better solution.
3, php-fpm's slow log, debug and exception troubleshooting artifact:
request_slowlog_timeout sets a timeout parameter, 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 executed too slowly.
You can see the common problems of network reading exceeding and MySQLquerying being too slow. If you follow the prompt information to troubleshoot the problem, you will have a clear direction.
php-fpm under php 5.3+ no longer supports commands such as /usr/local/php/sbin/php-fpm (start|stop|reload) that php-fpm previously had. You need to use Signal control:
The master process can understand the following signals
INT, TERM immediately terminate QUIT smoothly terminate USR1 reopen the log file USR2 smoothly reload all worker processes and reload configuration and binary modules
Example:
php-fpm Close:
kill -INT cat /usr/local/php/var/run/php-fpm.pid
php-fpm Restart:
kill -USR2 cat /usr/local/php/var/run/php-fpm.pid
Check the number of php-fpm processes:
ps aux | grep -c php-fpm
8. When executing php from the command line, it prompts that the command cannot be found
-bash: /usr/bin/php: No such file or directory
vi /etc/profile
Add a line of configuration at the bottom of the file
export PATH=/usr/local/php /bin:$PATH
Save and exit
source /etc/profile
The above is the detailed content of Sample code sharing explained by php-fpm. For more information, please follow other related articles on the PHP Chinese website!