ProxySQL 本身是一款非常棒的MYSQL 中间件的开源产品, 在公司运行了一段时间后,突然一天报警,所在机器的CPU 出奇的高,之前在测试系统, 预生产, 以及生产系统均没有出现问题. 开始未来紧急解决问题,重新启动了proxysql服务,并查看错误日志.
PROXYSQL 的系统版本的2.012 MYSQL 的版本是8.011 , PROXYSQL 的错误在上边. 但后期又继续发生了类似的问题, 并且其中有一次,重新启动PROXYSQL 后在 1- 2秒后, 问题重复,CPU 又开始标高,但CPU 等其他指标都比较低.
随后我们针对PROXYSQL 进行了压缩, 通过模仿高并发连接, 1000并发,不断的进行数据访问, 以及模拟突然的连接失效(断掉), 看看PROXYSQL 本身是不是出现的我们遇到的类似的问题.
在压力测试的过程中,PROXYSQL 系统本身没有出现任何异常的情况, CPU 始终在 %3以下, 在压力测试超过1000并发后, 并且PROXYSQL 最大设置的MAX Connection 1000 的情况下, PROXYSQL 在短时间有CPU 消耗达到25%的情况. 但整体的情况是稳定的.
那到底什么导致了PROXYSQL 系统的CPU 在某个时间段突然超高并且只能进行相关的重启后,CPU 才能下降.
这里和公司的网络安全人员进行了相关的配合,其中发现在漏洞扫描期间,PROXYSQL 有CPU 超高的时间匹配度.随后网络安全人员,进行了如下测试,
PROXYSQL
在漏洞扫描程序扫描时, 会对PROXYSQL 开放的 X11 协议端的端口进行扫描,在扫描时会反馈,下面的信息, 8.0.5 是在PROXYSQL 设置的,因为如果使用了MYSQL 8 后在PROXYSQL 中的version 信息不设置的情况下, 会导致JAVA 程序访问MYSQL的问题, 因为8.0以后的MYSQL 去掉了 query_cache , 但如果PROXYSQL 不设置版本,则 JAVA 的封包的程序会回馈, query_cache 找不到的 问题, 而 mysql_native_password 也是因为兼容大部分MYSQL 原理的程序登录的方式,将MYSQL 的默认密码验证的方式调整成原来5.X的方式.
所以这里漏扫程序会对敏感词 password 展开尝试性的密码匹配库的嗅探工作,而这样的工作导致,proxysql 在X11 端口中出现问题,进入一个死循环.
最终导致PROXYSQL 出现CPU 超高的问题.
解决方案: 在防火墙的IPS 模块对无效请求的数据包进行过滤(其实网络的问题,我不大理解到底IPS 是什么,怎么就对无效请求的数据包进行过滤,就避免了PROXYSQL 的CPU 不在提高,回来还的深入的问一下网络人员)
另外对其中一个参数,mysql-threads 在解决问题的时候,有人提出加大proxysql 中的 mysql-threads 的线程数,提高 proxysql 处理的速度,降低CPU 的 usage 的百分比.
实际这样的想法是错误, mysql-threads 本身针对当前CPU 的数量进行的设置,PROXYSQL 本身针对系统的运行期间,CPU 主要消耗在 SYSTEM CPU ,而不是USER CPU , 这里的意思是CPU 主要是消耗子在将信息从 客户端发送给MYSQL 以及信息专递回 客户端的, 如果 USER CPU 本身消耗的很高的情况下,则说明PROXYSQL 在处理数据方面有问题, 例如设置了太多的规则,导致一个SQL 在规则方面耗费的CPU 较多的情况.
另外盲目调整 mysql-threads 本身就是一个问题, 如果CPU 本身CORE 就很少,但是PROXYSQL 使用CPU 较多, 调整mysql-thread 更大的情况下,会造成CPU 上下文切换比较频繁,最终导致CPU 更加的繁忙.
所以如果CPU 高先分析以下几个问题
1 CPU 在什么 时间点高,是一直高还是有时间段
2 如果是有时间点的高,则考虑业务,或者业务触发的某些业务量上涨后的问题
3 如果是CPU 一直高,则考虑是由于一些BUG 或者 非业务的问题造成的,主要就要去查看日志,和进行STRACE 问题了, 难度可能就有提高了,另外PROXYSQL 中的设置的规则太多也可能会造成相关的问题.
