tidb-server的CPU居高不下的问题

[GangShen]

这个可以考虑升级一下集群，因为我们从v2.1.8版本之后对kill有很多改良

[青梅论IT (青梅)]

2019/10/29 21:04:23.765 server.go:314: [info] con:235354 new connection 10.33.22.26:22341

2019/10/29 21:04:23.844 set.go:180: [info] con:235354 character_set_results=NULL

2019/10/29 21:04:23.845 set.go:180: [info] con:235354 autocommit=1 2019/10/29 21:04:23.848 compiler.go:78: [warning] [EXPENSIVE_QUERY] SELECT a.accountNumber, c.enterpriseName, c.enterpriseCode, a.realName, c.businessDevelopmentIdentify , a.status, SUM(b.amount) AS amount, SUM(b.usableAmount) AS usableAmount , SUM(b.freezeAmount) AS freezeAmount, d.enterpriseName AS agentName FROM (PartyAccount a, Account b, Enterprise c) LEFT JOIN AgentRelated d ON c.enterpriseCode = d.enterpriseCode WHERE c.enterpriseName = ‘XXX’ LIMIT 0, 20;

[青梅论IT (青梅)]

很奇怪的是，我有两台TIDB-SERVER，因为走的是负载均衡，开发的同事运行了好几次，两台都有那条SQL的进程，奇怪的是，一台是有能找到kill的信息，一台找不到。刚才已经上传语句，请大佬们看一下。

[青梅论IT (青梅)]

两天了，CPU还是居高不下

[GangShen]

嗯，这个可能是2.1.8版本kill线程时没有真正kill掉线程，后续版本对这个有优化

[青梅论IT (青梅)]

如果现在把进程真正的停下来，请问有没有什么办法？

[青梅论IT (青梅)]

主要是怕影响现有的业务，CPU一直居高不下，担心对生产产生不良的影响或者灾难性的影响。

[GangShen]

tidb前端如果是有负载均衡的，可以考虑逐台重启一下tidb节点

[青梅论IT (青梅)]

好的，谢谢大佬们的细心的解答。