max_children=40, each child occupies an average of 20M-30M memory. The more children, the more concurrencies that can be accepted at the same time. Generally, the value of children is the highest number of concurrencies on the website + a floating value. This value is then × the memory usage, which is what you need memory used.
max_requests = N means that after each child accepts N requests, it will kill itself and then re-establish a child.
PV / max_children = the number of requests accepted by each child [The default default is to only call the PHP program once per browse, maybe asynchronously? What about the interface? ]
For example, the above value is 1000, and you define 10240, then it will take more than 10 days for fpm to kill children and rebuild. If there is a memory leak, it will cause the process to occupy too much Too much memory cannot be released, which reduces fpm's processing capabilities and produces some inexplicable errors.
But if you set this value too small, fpm will frequently kill children and rebuild, which will also cause additional overhead.
Of course the best optimization is to constantly debug and find a balance point based on the operation of your website.
There is also a lazy approach to max_children, If your php is 5.3, then you can set the style of fpm to apache-like, then the number of children will be Automatically controlled by fpm. The corresponding configuration parameters are
start_servers: Number of starting processes
min_spare_servers: Minimum number of processes
max_spare_servers: Maximum number of processes
When the server is relatively idle, fpm will actively kill some redundant children. Used to save resources, when the server is busy, the server will automatically create more children.
#########################
Nginx 502 Bad Gateway means that the requested PHP-CGI has been executed, but due to some The reason (usually a problem of reading resources) is not completed and the PHP-CGI process is terminated.
Generally speaking, Nginx 502 Bad Gateway is related to the settings of php-fpm.conf.
php-fpm.conf has two crucial parameters, one is max_children,
the other is request_terminate_timeout, but this value is not universal and needs to be calculated by yourself.
A 502 problem occurs during installation and use. It is usually because the default php-cgi process is 5. It may be that there are not enough phpcgi processes to cause 502. /usr/local/php/etc/php-fpm needs to be modified. conf will increase the max_children value appropriately.
The calculation method is as follows:
If your server performance is good enough, broadband resources are sufficient, and there are no infinite loops or bugs in the PHP script, you can directly set request_terminate_timeout to 0s. The meaning of 0s is to let PHP-CGI continue to execute without time limit. And if you can't do this, that is to say, your PHP-CGI may have a BUG, or your bandwidth is not sufficient, or other reasons cause your PHP-CGI to freeze, then it is recommended that you assign a value to request_terminate_timeout. This value can be set according to the performance of the server. Generally speaking, the better the performance, the higher you can set it, anywhere from 20 minutes to 30 minutes.
And how is the value of max_children calculated? In principle, the larger the value, the better. If there are more php-cgi processes, it will be processed quickly and there will be fewer queued requests. Setting max_children also needs to be set according to the performance of the server.
Generally speaking, the memory consumed by each php-cgi on a server is about 20M under normal circumstances.
According to the official answers, we checked the related possibilities and combined with the answers from netizens, we came up with the following solutions.
1. Check the number of processes of php fastcgi (max_children value)
Code: netstat -anpo | grep "php-cgi" | wc -l
5 (if 5 is displayed)
2. Check the current process
Code: top
Observe the number of fastcgi processes. If the number of processes used is equal to or higher than 5, it means that it needs to be increased (depending on the actual situation of your machine) )
3. Adjust the relevant settings of /usr/local/php/etc/php-fpm.conf
max_children can have up to 10 processes, with 20MB of memory per process, up to 200MB.
The execution time of request_terminate_timeout is 60 seconds, which is 1 minute.
############################################ ##
The website operating environment is Nginx +php fastcgi mode. The operation has been unstable in the past few days, always making errors and reporting 502 errors.
I asked a former colleague for advice today and he told me to check the php-fpm log. A lot of useful information is recorded there.
So I checked and found that there were indeed a lot of error messages:
Sep 30 08:32:23.289973 [NOTICE] fpm_unix_init_main(), line 271: getrlimit(nofile): max:51200, cur:51200
If it is inconsistent with nginx.conf: worker_rlimit_nofile 65500; it must be checked, set and restart the service
Mar 01 14:39:15.881047 [NOTICE] fpm_children_make(), line 352: child 12364 (pool default) started
Mar 01 14 :39:21.715825 [NOTICE] fpm_got_signal(), line 48: received SIGCHLD
Mar 01 14:39:21.715899 [NOTICE] fpm_children_bury(), line 215: child 11947 (pool default) exited with code 0 after 175.443305 seconds from start
Some error messages are easy to explain. You can check the information directly online.
After searching, I finally summarized the following optimization strategies:
1. Improve the server's file handle and open it
# vi /etc/security/limits.conf plus
* soft nofile 65500
* hard nofile 65500
2. Increase the number of open process files of nginx
nginx.conf: worker_rlimit_nofile 65500;
3. Modify php -fpm.conf file mainly needs to be modified in 2 places.
Command ulimit -n to check the limited number of open files. The option rlimit_files in php-fpm.conf must be consistent with this value.
4,
# vi /etc/sysctl.conf
Add
fs.file-max=65500 at the bottom
After the above modifications, restart PHP. /usr/local/webserver/php/sbin/php-fpm restart
Check whether ulimit -n takes effect, otherwise restart the server or the configuration of /etc/sysctl.conf and /etc/security/limits.conf will take effect
So far, the above error message has not appeared. Everything runs fine.