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

Posted 2022-12-11 朱培

---------------------------------------------------------------------------------------------
[版权申明：本文系作者原创，转载请注明出处] 
文章出处：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代码，找到问题的原因很重要。