项目上线一年,一个数据表使用下面这个sql,查询10分钟,46亿多条数据,是不是很惊异,想不到吧,我当时看到这个数字,我觉得绝对是程序BUG了,然而事实是就是这么多,言归正传
select id from table_name
在11月刚开始的几天,客户那边突然反映了一个问题,系统访问时快时慢的,麻烦我们给看一下找出原因并解决掉,期初以为是后台服务运行应用的uwsgi日志太庞大,当晚将日志分割了出来,这里有个注意点,Linux系统的文件是不可以直接删除的,因为Linux文件系统有个信号标的问题,这里不多叙述,需要知道的朋友自行百度一下.
清空日志指令:
echo ""> uwsgi.log
最好是项目上线前就Nginx和uwsgi的日志分割脚本都写好免得尴尬
第二天下午,客户反映没有解决问题;好了这下就头大了,从头开始排查,这里总结了一套关于这个问题的一个排查方案:
1:因为项目是前端分离的系统,首先确认是前端还是后台的问题,从这个地方可以看出来
Request sent(请求发送):这个有值说明你前端请求了,我这里前端请求花费了90微秒
Waiting(TTFB)后台响应时间:前端请求后台共计花费了207毫秒,这个地方如果时间很长,那就可以确认是后台的问题
2.请求到后台Nginx路由分发,首先查看Nginx日志,看看是否有报错,如果没有报错就继续接下来查看;
3.路由分发后再到uWSGI应用中进行请求处理,uWSGI日志没有报错;
4.确认是否是硬件问题,CPU,硬盘,内存;
5.查看CPU使用率的问题,如果CPU占用率长时间达到90以上,根据这个看看什么进程占用的,看看是不是有什么接口程序计算过于频繁,如果是CPU使用率的问题,基本可以确认是接口的问题,汇总一下每个接口的请求频率,到这里我想各位应该就能找出问题了吧