[Beijing website production] The relationship between the PHP CGI process CPU 100% and the file_get_contents function

In large and medium-sized websites, API interface calls based on HTTP protocol are common. PHP programmers like to use simple and convenient file_get_contents（“ //example.com/ ") function to obtain the return content of a URL, but if //example.com/ The website responds slowly, and file_get_contents() will be stuck there all the time without timeout.

We know that in php. ini, there is a parameter max_execution_time that can set the maximum execution time of PHP scripts. However, in php cgi (php fpm), this parameter does not work. The following parameters in the php-fpm.conf configuration file can really control the maximum execution time of PHP scripts:

1. The timeout (in seconds) for serving a single request after which the worker process will be terminated    
2. Should be used when 'max_execution_time' ini option does not stop script execution for some reason    
3. '0s' means 'off'    
4. < value   name = "request_terminate_timeout" > 0s </ value >    

The default value is 0 seconds, which means that the PHP script will always be executed. In this way, when all php cgi processes are stuck in the 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. It is necessary to modify this parameter and set the maximum execution time of a PHP script, but it does not cure the symptoms. For example, if it is changed to 30s, if file_get_contents() is slow to obtain web page content, it means that 150 php cgi processes can only process 5 requests per second. It is also difficult for WebServer to avoid "502 Bad Gateway".

To achieve a thorough solution, PHP programmers can only change the direct use of file_get_contents（“ //example.com/ "), but slightly modify it, add a timeout, and implement HTTP GET requests in the following ways. If you feel troublesome, you can encapsulate the following code into a function.

1. <? php     
2. $ ctx  =  stream_context_create (array(    
3.    'http' = >  array(    
4.        'timeout' = > 1//Set a timeout in seconds
5.        )    
6.    )    
7. );     
8. file_get_contents(" //example.com/ ", 0, $ctx);    
9. ?>    

Of course, this is not the only reason that causes 100% CPU of the php cgi process. How can we determine that it is caused by the file_get_contents() function?

First, use the top command to view php cgi processes with high CPU utilization.

1. top - 10:34:18 up 724 days, 21:01,  3 users,  load average: 17.86, 11.16, 7.69 
2. Tasks: 561 total,  15 running, 546 sleeping,   0 stopped,   0 zombie 
3. Cpu(s):  5.9%us,  4.2%sy,  0.0%ni, 89.4%id,  0.2%wa,  0.0%hi,  0.2%si,  0.0%st 
4. Mem:   8100996k total,  4320108k used,  3780888k free,   772572k buffers 
5. Swap:  8193108k total,    50776k used,  8142332k free,   412088k cached 
6.   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                            
7. 10747 www       18   0  360m  22m  12m R 100.6 0.3    0:02.60 php-cgi                                                            
8. 10709 www       16   0  359m  28m  17m R 96.8  0.4    0:11.34 php-cgi                                                            
9. 10745 www       18   0  360m  24m  14m R 94.8  0.3    0:39.51 php-cgi                                                            
10. 10707 www       18   0  360m  25m  14m S 77.4  0.3    0:33.48 php-cgi                                                            
11. 10782 www       20   0  360m  26m  15m R 75.5  0.3    0:10.93 php-cgi                                                            
12. 10708 www       25   0  360m  22m  12m R 69.7  0.3    0:45.16 php-cgi                                                            
13. 10683 www       25   0  362m  28m  15m R 54.2  0.4    0:32.65 php-cgi                                                            
14. 10711 www       25   0  360m  25m  15m R 52.2  0.3    0:44.25 php-cgi                                                            
15. 10688 www       25   0  359m  25m  15m R 38.7  0.3    0:10.44 php-cgi                                                            
16. 10719 www       25   0  360m  26m  16m R  7.7  0.3    0:40.59 php-cgi 

Find the PID of the php cgi process with 100% CPU and trace it with the following command:

1. strace -p 10747 

If the screen displays:

1. select(7, [6], [6], [], {15, 0})        = 1 (out [6], left {15, 0}) 
2. poll([{ fd = six ,  events = POLLIN }], 1, 0)     = 0 (Timeout) 
3. select(7, [6], [6], [], {15, 0})        = 1 (out [6], left {15, 0}) 
4. poll([{ fd = six ,  events = POLLIN }], 1, 0)     = 0 (Timeout) 
5. select(7, [6], [6], [], {15, 0})        = 1 (out [6], left {15, 0}) 
6. poll([{ fd = six ,  events = POLLIN }], 1, 0)     = 0 (Timeout) 
7. select(7, [6], [6], [], {15, 0})        = 1 (out [6], left {15, 0}) 
8. poll([{ fd = six ,  events = POLLIN }], 1, 0)     = 0 (Timeout) 
9. select(7, [6], [6], [], {15, 0})        = 1 (out [6], left {15, 0}) 
10. poll([{ fd = six ,  events = POLLIN }], 1, 0)     = 0 (Timeout) 
11. select(7, [6], [6], [], {15, 0})        = 1 (out [6], left {15, 0}) 
12. poll([{ fd = six ,  events = POLLIN }], 1, 0)     = 0 (Timeout) 
13. select(7, [6], [6], [], {15, 0})        = 1 (out [6], left {15, 0}) 
14. poll([{ fd = six ,  events = POLLIN }], 1, 0)     = 0 (Timeout) 
15. select(7, [6], [6], [], {15, 0})        = 1 (out [6], left {15, 0}) 
16. poll([{ fd = six ,  events = POLLIN }], 1, 0)     = 0 (Timeout) 
17. select(7, [6], [6], [], {15, 0})        = 1 (out [6], left {15, 0}) 
18. poll([{ fd = six ,  events = POLLIN }], 1, 0)     = 0 (Timeout) 
19. select(7, [6], [6], [], {15, 0})        = 1 (out [6], left {15, 0}) 
20. poll([{ fd = six ,  events = POLLIN }], 1, 0)     = 0 (Timeout) 

Then, it can be determined that the problem is caused by file_get_contents().