OneSQL :: 如何对MySQL数据库进行CPU资源有效绑定, 保证私有云运行稳定!

最近优化OneSQL高并发补丁时,花了不少时间进行压测,观察CPU的利用率以及并发效率。如何更加充分地利用CPU资源,避免各种各样的锁(spinlock)争用,使之在较少CPU核心(20个Cores)时能够压测出较多核心(22个核或24个Cores)的处理能力,是一件非常有意思的事情。结合多个的客户真实场景,我们总结出了一套自认为不错的MySQL资源绑定策略,需要从多个层面来进行有效的CPU资源控制,才能满足各种各样业务场景的需要。如下图所示:

首先,MySQL不应当用完OS所能看到的所有CPU资源,OS需要做进程调度,需要处理网络中断,需要处理磁盘的IO操作,还需要执行你的Top或Perf Top等命令,更需要实时响应你的远程登录需求。一般会建议保留2个Core的CPU资源给OS,这样可以确保有足够的CPU来处理上述的任务,也不会引起过高的Load值以减少负载报警。

其次,MySQL数据库的进程可以分为用户线程(和客户端会话相对应的线程)和后台线程,其实和OS类似,后台线程需要处理新的连接,需要处理数据缓存的IO,需要监听新的连接请求,需要检测死锁,需要清理Undo表空间,需要处理Binlog复制或回放等。用户线程不应当完全占据所有可用的CPU资源,以免MySQL实例失去响应。一般会建议保留1-2个Core的CPU资源给MySQL的后台进程。

第三,一个MySQL数据库下通常会建多个Database(可以理解为多个Schema),有不少的业务场景下,希望能够减少不同Database/Schema负载相互干扰的情况,即任何一个Database或Schema的SQL处理不应当用完所有的CPU资源,最好能够配置不同的Database/Schema最多能够使用CPU资源。

第四,一个MySQL数据库通常会有多个不同的应用(客户端)连接进来,为了防止应用变更中的意外慢SQL问题,也希望能够限制单个客户端机器所能使用的MySQL服务器端的CPU资源,这样即使代码中不小心写了几个未经优化的SQL语句,或者进入死循环的业务逻辑,在预发布环境下也不会过多地影响线上的稳定运行。

再往上走其实还有理细的资源绑定的需求,比如不同程序模块之间的CPU资源限制,不同商品之间的CPU资源控制(比如互联网的秒杀),或者不同SQL语句之间的CPU资源控制(比如类似全表扫描/缺少索引这样性能极差的SQL语句),可以在很多的层面上进行CPU资源限制,以防止一个极小的点产生过大的影响,OneSQL在所有这些层面上都可以有效地进行CPU资源控制,以确保私有云环境的MySQL稳定运行。