记一次服务器性能问题排查经过

Posted 朱培

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了记一次服务器性能问题排查经过相关的知识,希望对你有一定的参考价值。

---------------------------------------------------------------------------------------------
[版权申明:本文系作者原创,转载请注明出处] 
文章出处:https://blog.csdn.net/sdksdk0/article/details/84565356

作者:朱培      ID:sdksdk0     
--------------------------------------------------------------------------------------------

最近,测试妹子和前端向我反映说接口查询起来很慢,他们那边加载要挺久的,我满满自信的说不科学啊,我过去一看,好像的确是挺慢的,然后就决定来把这个问题解决一下。因为我的API服务以及部署在我们部门目前性能最好的服务器上面了,所以应该不是API服务器这个节点的问题,然后屁颠屁颠的查sql,分析发现有个词云表的查询非常慢,在打印sql的log的时候居然等了好几秒钟,语句如下,非常简单

select word,sum(num) as num from c_key_words where 1=1 GROUP BY word ORDER BY num desc limit 200 

我觉得可以从这里入手,然后打开sql分析,一查发现,好家伙,费了我7s才出结果,可是我这个表目前只有2万条数据,不应该这么慢的,那来看看索引情况,

嗯,看到并没有索引,于是加个索引看看

通过explain分析,发现索引已经加上了,但是依然还需要7s才能出结果,我觉得这个不科学啊,然后转去mysql的服务器上面查询,看下连接数:

mysqladmin -uroot -p status;

然后发现是连接数过多导致的吧

Uptime: 71675  Threads: 1999  Questions: 7529317  Slow queries: 98517  Opens: 628  Flush tables: 1  Open tables: 606  Queries per second avg: 105.048

然后简单粗暴的重启了。。。。。。。

重启之后:

Uptime: 51  Threads: 19  Questions: 6783  Slow queries: 0  Opens: 414  Flush tables: 1  Open tables: 407  Queries per second avg: 133.000

问题解决了,但是为什么呢?是哪个程序导致的

因为目前用的不可能有这么多人,然后想到了肯定是哪里开启了连接但是并没有关闭,如何想到了我这边使用了websocket,莫不是使用完成后没有关闭连接。

然后去查websocket这台机器的日志,发现连接数果然过大,因为开发服务器这边连接的数量不可能超过20,所以很有异常

然后把前端抓过来,然后通过查找他代码,发现是网页刷新的时候没有关闭websocket,然后让他进行关闭。

我这边重启websocket服务,修改数据库my.cnf最大连接线程数,将其减小到和合理值,重启数据库服务,

搞定!

所以说遇到问题得综合分析,不一定一开始就去大动干戈的优化后端API代码,找到问题的原因很重要。

以上是关于记一次服务器性能问题排查经过的主要内容,如果未能解决你的问题,请参考以下文章

记一次线上FGC问题排查

记一次线上FGC问题排查

记一次外部agent侵入导致的OOM排查过程

解Bug之路-记一次中间件导致的慢SQL排查过程

记一次线上事故,redis 的keys问题,cpu引起的性能问题

记一次中间件导致的慢SQL排查过程