MYSQL CPU部分单核占满是否会影响建立数据库连接效率

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 调度的工作原理。

系统中断和上下文切换是否可以说明就是大量的系统调用请求异常。

看完上述内容是否对您有帮助呢？如果还想对相关知识有进一步的了解或阅读更多相关文章，请关注行业资讯频道，感谢您对的支持。