【PHP】nginx下file_get_contents导致cpu 100%的问题

昨天早上，线上主站点（nginx + fastcgi）大图详情页面打开缓慢，出现了很多502和504的错误，且服务器压力过大，几乎处于拒绝服务状态。Top命令查看服务器的资源使用情况，发现cpu飙升到100%且持续1-2分钟居高不下。而且，打开nginx的错误日志，发现有很多请求都是如下的状态：

由于大图详情页面并没有需要消耗cpu资源的计算，只有获取图片信息和相关推荐及评论的逻辑，因而起初怀疑是nginx配置导致的问题。后来发现，只有在某些情况下会出现这样的问题。无奈之下，只好对各个模块的请求时间记录并通过error_log将统计信息记录到文件。三个小时之后，打开统计文件，发现其中一个模块的加载时间极不稳定，有时甚至会操过120s，这显然是造成nginx 502错误的原因之一。Check相应的代码发现，对搜索接口的调用，是直接通过file_get_contents(API)的方式获取的。由于file_get_contents是阻塞的I/O方式，且默认没有设置超时，因而如果搜索接口在长时间没有返回数据的情况下，会一直占用系统的资源，从而导致了nginx的502 bad gateway错误。张宴的博客中，对这一现象做了详细的解释和描述（地址：http://blog.s135.com/file_get_contents/）。在文中，作者给的解决方案是使用stream的timeout参数，使file_get_contents的socket连接强制超时，具体方案是：

$ctx = stream_context_create(array(  
		'http' => array(  
			'timeout' => 5 //设置一个超时时间，单位为s 
		)  
	)  
);  
file_get_contents(API, 0, $ctx);

经过尝试后发现，在很多情况下，这样的超时设置是可以的，但是偶尔也会有超时设置失效的情况，而且，file_get_contents无法对错误的详细信息进行追踪，因而我们在考虑之后，还是决定放弃file_get_contents，而使用更加强大的curl来完成相应的功能，并通过CURLOPT_TIMEOUT和CURLOPT_CONNECT_TIMEOUT限制搜索接口的连接时间和请求时间。且为了保证搜索的结果，会尝试3次连接，如果失败，则使用default的数据来填充。这样设置之后，基本上很少出现502 bad gateway的错误了。

这里还是记录几点备忘：

1.  出现类似的错误时，不要急于修改nginx的配置，因为如果很多业务都正常儿只有部分业务不正常时，很有可能是该业务中含有比较耗时的操作或者错误的逻辑，要先对该业务进行排查，尤其是，很多developer并没有修改服务器配置文件的权限。

2.  线上的业务一般容错性要求较高，常常需要果断摈弃例如file_get_contents这样的看似便利但实际有很多缺陷的函数，而使用功能更加完善的类库代替。

3.  很多时候，进程异常时（如cpu占用较高），不要急于kill掉这个“现场”，不妨strace–p pid 追踪一下进程的系统调用，常常会有意想不到的收获（比如，发现另一很难发现的bug）。关于strace的使用，推荐个比较好的文章：

http://blog.wgzhao.com/2012/01/16/5-simple-ways-to-troubleshoot-using-strace/