记录一次服务器CPU 100%的解决过程

 昨天客户反馈业务系统很慢，并且偶尔报错。

查看nginx日志：

[root@s2 nginx]# tail log/error.log

2017/03/14 12:54:46 [error] 17042#17042: *9305256418 upstream timed out (110: Connection timed out) while reading response header from upstream

 

看来是请求超时了。再查看nginx.conf配置，读取时间已经设置得比较长了。

location ^~ /api/faqs
{
    proxy_pass http://api_faqs;
        proxy_redirect default;
    proxy_set_header   Host             $host;
    proxy_set_header   X-Real-IP        $remote_addr;
        proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
    proxy_connect_timeout 10;
    proxy_send_timeout 10;
    proxy_read_timeout 120;
}

 

看来问题在后面的应用服务器，这里的接口后面是有三个.Net系统在服务，分布在两台windows服务器上。

其中一台服务器上有两个w3wp进程负责处理该接口数据，另一台有一个进程处理。发现前者cpu使用已经100%，后者cpu使用也高达80%.

并且对应的.Net进程内存占用高达两个G。

奈何dotTrace和dotMemory已通过了试用期，只能本身看了。

 

使用事件查看器查看每秒请求数 Request/Sec.(在asp.net application 4里面)，单w3wp进程发现请求实际上每秒约200多个，这个水平是低于平时的。

看来已经受cpu影响，请求处理能力大幅降低了。

 

查看数据库服务器，top 一下，mysql cpu 使用780%+（8核32g，至关于cpu使用也是100%了）。

看来是数据库问题，查top sql，qps。直接用sqlyog查看进程状态就行。

发现果真是该接口同时有几十个链接，在查询数据。

对看到的sql 作索引和查询优化后，单条sql执行时间已是0ms。这时候数据库的cpu压力小了点，可是 应用服务器仍是 100%。

 

最后只能分析代码了，由于该接口是须要一次性返回大量数据。

用redis和.Net Cache作了两级缓存，感受是缓存没有命中，屡次请求数据库了。

偷摸暂停接口功能，复制一样功能的接口，打上全流程日志查看，发现单次请求测试接口其实正常。

问题可能在高并发上，从代码看有几个地方有问题，最后加锁解决。