13518219792
MYSQL CPU部分单核占满是否会影响建立数据库连接效率，很多新手对此不是很清楚，为了帮助大家解决这个难题，下面小编将为大家详细讲解，有这方面需求的人可以来学习下，希望你能有所收获。
问题描述：
cpu 瞬间爆满，前台应用程序报出 too many connection错误，mysql ERROR日志报出[Warning] Too many connections，操作系统日志报出： kernel: TCP: time wait bucket table overflow。
主机的资源情况如下：
1.CPU 总体资源不高，但出现单核使用率100% 情况
2.CPU 系统中断和上下文切换指标同时突然上涨。
3.数据库所在磁盘IO几乎打满。
数据库情况：
1.监控采集程序连不上数据库，无法采集到数据库指标， 说明数据库连接在短时间内突然激增，无逐渐上升趋势。
2.故障期间无慢日志。
3.抓取BINLOG，故障刚开始后无新事务产生。
4.日常连接数基本在500以下，故障时达到阈值3000，连接数达到阈值是个结果，问题是找出为什么会有连接不释放。
5.登上数据库时有发现大量会话是unauthenticated user状态
业务情况：
1.正属业务高峰期，但并无明显的业务突然上涨情况
2.业务应用采用jdbc连接池，连接异常时会不断重试连接
思路：
故障时有同事执行了16并行的pigz 操作，这也是以上主机cpu及IO资源异常问题，怀疑此异常即影响了数据库的连接。而主要是CPU 的请求异常影响了不断涌进来的数据库连接请求。
我的判断依据：
1.连接数瞬间爆满是个结果，原因是因为前面大部分的连接HANG住。
2.那么连接可能hang在那个阶段呢：
1）没有慢查询，说明不是慢sql 问题
2）binlog没有大量超长事务，甚至故障期间没有事务产生。说明非长事务问题
3）sleep的连接没有释放？首先程序并未做过任何变动，连接无法断开可能是数据库本地异常，但如果是这样，我认为连接开始就不能正常连接了。因此连接应该能够正常断开
4）因此我想连接hang在了连接阶段了。加上之前看到大量会话会在unauthenticated user 状态，这阶段应该是实在客户端与数据库建立了tcp连接，然后进行认证，分配线程的阶段，如果此时数据库获取CPU资源有问题是不是意味着连接被放慢了，甚至HANG住。
我做了个实验，在CPU使用率持续100% 的情况下发起大量的连接在数据库连接期间对CPU的需求还是比较大
此时也是能看到较多的unauthenticated user 会话!
目前仍无法肯定根因：
因为，CPU 只是一部分满而已，这需要进一步了解LINUX CPU 调度的工作原理。
系统中断和上下文切换是否可以说明就是大量的系统调用请求异常。
看完上述内容是否对您有帮助呢？如果还想对相关知识有进一步的了解或阅读更多相关文章，请关注创新互联-成都网站建设公司行业资讯频道，感谢您对创新互联的支持。
