PHP-CGI 进程 CPU 100% 与 file_get_contents 函数解析

前端之家收集整理的这篇文章主要介绍了PHP-CGI 进程 CPU 100% 与 file_get_contents 函数解析前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
php-cgi 进程 cpu 100% 与 file_get_contents 函数的关系感兴趣的小伙伴,下面一起跟随编程之家 jb51.cc的小编两巴掌来看看吧!
有时候,运行 Nginxphp-cgi(PHP-fpm) Web服务的 Linux 服务器,突然系统负载上升,使用 top 命令查看,很多 php-cgi 进程 cpu 使用率接近100%。后来,我通过跟踪发现,这类情况的出现,跟 PHP 的 file_get_contents() 函数有着密切的关系。

大、中型网站中,基于 HTTP 协议的 API 接口调用,是家常便饭。PHP 程序员们喜欢使用简单便捷的 file_get_contents("http://example.com/") 函数,来获取一个 URL 的返回内容,但是,如果 http://example.com/ 这个网站响应缓慢,file_get_contents() 就会一直卡在那儿,不会超时。

我们知道,在 PHP.ini 中,有一个参数 max_execution_time 可以设置 PHP 脚本的最大执行时间,但是,在 php-cgi(PHP-fpm) 中,该参数不会起效。真正能够控制 PHP 脚本最大执行时间的是 PHP-fpm.conf 配置文件中的以下参数:
The timeout (in seconds) for serving a single request after which the worker process will be terminated Should be used when 'max_execution_time' ini option does not stop script execution for some reason '0s' means 'off' <value name="request_terminate_timeout">0s</value>

默认值为 0 秒,也就是说,PHP 脚本会一直执行下去。这样,当所有的 php-cgi 进程都卡在 file_get_contents() 函数时,这台 Nginx+PHP 的 WebServer 已经无法再处理新的 PHP 请求了,Nginx 将给用户返回“502 Bad Gateway”。修改该参数,设置一个 PHP 脚本最大执行时间是必要的,但是,治标不治本。例如改成 30s,如果发生 file_get_contents() 获取网页内容较慢的情况,这就意味着 150 个 php-cgi 进程,每秒钟只能处理 5 个请求,WebServer 同样很难避免“502 Bad Gateway”。

要做到彻底解决,只能让 PHP 程序员们改掉直接使用 file_get_contents("http://example.com/") 的习惯,而是稍微修改一下,加个超时时间,用以下方式来实现 HTTP GET 请求。要是觉得麻烦,可以自行将以下代码封装成一个函数PHP代码如下:

<?PHP 
/**
 * php-cgi 进程 cpu 100% 与 file_get_contents 函数的关系
 * @param 
 * @arrange (512.笔记) jb51.cc
 **/
$ctx = stream_context_create(array( 'http' => array( 'timeout' => 1 //设置一个超时时间,单位为秒 ) ) );
file_get_contents("http://example.com/",$ctx);
?>

当然,导致 php-cgi 进程 cpu 100% 的原因不只有这一种,那么,怎么确定是 file_get_contents() 函数导致的呢?首先,使用 top 命令查看 cpu 使用率较高的 php-cgi 进程。
  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
找其中一个 cpu 100% 的 php-cgi 进程的 PID,用以下命令跟踪一下:
  1. strace -p 10747
     
  如果屏幕显示
  1. select(7,[6],[],{15,0}) = 1 (out [6],left {15,0})
     
  2. poll([{fd
    =
    6
    ,
    events
    =
    POLLIN
    }],1,0) = 0 (Timeout)

     
  3. select(7,0})
  4. poll([{fd
    =
    6
    ,0) = 0 (Timeout)
  那么,就可以确定是 file_get_contents() 导致的问题了。 原文链接:https://www.f2er.com/php/527948.html

猜你在找的PHP相关文章