Home  >  Article  >  Backend Development  >  What to do if php-cgi stops under Linux

What to do if php-cgi stops under Linux

王林
王林Original
2021-09-26 16:32:572336browse

The solution to php-cgi stopping under Linux is: change the nginx configuration item, reduce the number of FastCGI requests, and try to keep the buffers unchanged, such as [fastcgi_buffer_size 128k;].

What to do if php-cgi stops under Linux

#The operating environment of this article: linux 5.9.8, php 7, thinkpad t480 computer.

Foreword:

I accidentally discovered that a server in production (centos 5.2 64-bit 4G memory) always had the problem that the website could not be opened. Later, I went to the server to check and found that both nginx and php-cgi were running, but the cpu usage of php-cgi was 0 at this time. So I immediately checked the file handle limit:

ulimit -n

The result was: 1024, which is too small for services in production.

Most of the solutions given on the Internet are to directly enter

ulimit -SHn 51200 # 51200可自己根据应用调整

The disadvantage of this method is obvious. Once you log out, the settings will become invalid.

It is also said that the command should be written directly to /etc/rc.d/rc.local. Today I found a correct way.

Open /etc/security/limits.conf, inside There are very detailed comments. Find the following settings (insert if not)

The code is as follows

* soft nofile 51200
* hard nofile 51200

Log in again after exiting and check the number of handles. It has been correctly set to 51200.

If you encounter a similar situation, you can check to see if the number of file handles is set too small.

Solution to 502 Bad Gateway when accessing

Nginx 502 Bad Gateway means that the requested php-cgi has been executed, but for some reason (usually a problem with reading resources) The execution is not completed and the php-cgi process is terminated. Generally, websites with too high concurrency are prone to this error. There are many reasons why 502 Bad Gateway appears, but most people can solve it by modifying the parameters below.

Change several configuration items of nginx, reduce the number of FastCGI requests, and try to keep the buffers unchanged:

The code is as follows

fastcgi_buffer_size 128k;
fastcgi_buffers 2 256k;
fastcgi_busy_buffers_size 256k;
fastcgi_temp_file_write_size 256k;

Open /usr/local/php/etc /php-fpm.conf file, modify the following parameters:

The code is as follows

25
requests">2048
65535
30s
60s

request_terminate_timeout refers to the execution script time of fast-cgi, which defaults to 0s. The meaning of 0s is to let php-cgi continue to execute without time limit. If you set it to 0s here, then when a 502 Bad Gateway appears, the 502 status will continue and will not change. But if you set it to 5s, then php-cgi will automatically recover after 5s. This value can be set according to the performance of your server. Here I set it to 60s.

max_children represents the processing process of php-cgi. If max_children is set to a smaller value, such as 5-10, then php-cgi will be "very tired", the processing speed will be very slow, and the waiting time will be longer. If a request is not processed for a long time, a 504 Gateway Time-out error will occur. Setting max_children also needs to be set according to the performance of the server. As the number of processes increases, the memory usage will increase accordingly. Under normal circumstances, the memory consumed by each php-cgi is about 20M. Here I set it to 25.

The default static processing method of php-fpm will cause the php-cgi process to occupy memory for a long time and cannot be released. This is also one of the reasons for nginx errors, so you can change the processing method of php-fpm to apache -like mode.

After the modification is completed, execute lu-restart (LuManager server management system).

Recommended learning: php training

The above is the detailed content of What to do if php-cgi stops under Linux. For more information, please follow other related articles on the PHP Chinese website!

Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn