【案例】常驻查询引发的threadpool性能问题之二-创新互联
创新互联公司是一家从事企业网站建设、成都做网站、网站设计、行业门户网站建设、网页设计制作的专业网站制作公司，拥有经验丰富的网站建设工程师和网页设计人员，具备各种规模与类型网站建设的实力，在网站建设领域树立了自己独特的设计风格。自公司成立以来曾独立设计制作的站点上千家。ong>一 现象某业务单机4个实例中的一个实例出现连接数远高于其他三个实例（正常是4K，问题实例是8K+），但是这4个实例的配置完全相同。业务开发反馈为部分连接失败。
执行show processlist结果显示：
存在大量的Killed状态的连接126个，处于Connect状态的6K+，以及6个binlog dump连接(如果看了前面一篇文章是否有点触动，会不会是这个导致的？)
执行pt-pmp结果显示：
mysqld 十分的空闲
执行show engine innodb status：
不存在空闲大事务
二 处理
根据上一篇文章的知识，初步判断该数据库实例遇到为Thread Pool的部分group被阻塞了，（能把query堵在login阶段的大部分为threadpool调度的问题，当然也不排除是因为逻辑原因造成login中出现内部锁等待）
在调整thread_pool_oversubscribe后所有的Connect/Killed状态的连接全部消失，连接数恢复正常。
三 问题分析
虽然问题是解决了，但是还有大量的疑问存在，显然在原因未知的情况下，如果在业务高峰期意外出现类似现象，后果非常严重，因此我们开始挖掘深层次的原因。
【曲折】
既然调整thread_pool_oversubscribe后问题就解决了，很显然是有group被阻塞了，因此最重要的就是找出是什么阻塞了Thread Pool。
这次最能引起人注意的现象当然是这126个Killed状态的连接了，我们知道当连接在运行中，被kill后处于回滚阶段时，会显示Killed。一般来说这个阶段非常短暂（除非有大量的rollback工作，但是State信息是空的，显然不是在rollback），pt-pmp的结果也证明了这一点。最开始一直怀疑是这些Killed的连接阻塞了threadpool的某些group，但是想来想去没有想到合理的解释，这里浪费了很多的时间。
【柳暗花明】
在Killed session上走不通，那只能看看其他session了，这时发现被阻塞的Connect连接的thread id十分有规律:
- | 4261587 | unauthenticated user | connecting host | NULL | Connect | NULL | login | NULL |
- | 4261619 | unauthenticated user | connecting host | NULL | Connect | NULL | login | NULL |
- | 4261651 | unauthenticated user | connecting host | NULL | Connect | NULL | login | NULL |
- | 4261683 | unauthenticated user | connecting host | NULL | Connect | NULL | login | NULL |
- | 4261715 | unauthenticated user | connecting host | NULL | Connect | NULL | login | NULL |
- | 4261747 | unauthenticated user | connecting host | NULL | Connect | NULL | login | NULL |
文章名称：【案例】常驻查询引发的threadpool性能问题之二-创新互联
文章路径：http://scyanting.com/article/djedgj.html
