Fantacy
人工智能,智能运营,智能客服,企业知识管理系统(Kmaster,SuperKM)
posts - 86,comments - 163,trackbacks - 14

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

查看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做了两级缓存,感觉是缓存没有命中,多次请求数据库了。

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

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

 

posted on 2017-03-15 11:58 calmzeal 阅读(...) 评论(...) 编辑 收藏