文章目录
[+]
我们的做事紧张是nginx+PHP的环境的，在晚高峰流量大的时候，CPU总是首先成为瓶颈，如图1所示：
从这幅图看，晚高峰和白天比，CPU system time增长明显，并且花费了大部分的CPU资源。通过perf可以看到PHP利用了大部分的CPU资源，基于已知的这两个条件，我们通过strace查了一下PHP进程的系统调用干系。通过剖析，创造PHP在调用read函数的韶光花费偏长一些。如图2所示：
个中每次read函数均匀耗时11毫秒，这个数字看起来比较奇怪，印象当中我们现在的read调用该当是远低于这个数字。于是打开strace记录文件，创造里边有大量针对文件/dev/urandom的read操作都发生在socket要求后端http接口之前，且每次操作耗时为几十到上百毫秒不等。对付这种大量访问urandom的行为不解之时，疑惑这个行为可能和libcurl有关系，于是找到@wen7ng 同学帮忙看看代码里边的线索，终极定位到这个是libcurl中关于dns异步解析的一个特性（感兴趣的同学可以搜索一下c-ares干系的知识），于是我们重新编译libcurl干系的包，把--enable-ares关闭，PHP中对urandom的操作消逝，CPU在高峰期间system time占用高的问题也就办理了。如图3所示：
（图片来自网络侵删）
此时我大脑中带着两个问题，1. urandom在短韶光内大量read操作时,效率怎么这么低；2. libcurl中的c-ares特性比较适宜运用在什么环境下。
