内容简介:【问题】最近有台服务器比较频繁的CPU报警,表现的特征有CPU sys占比偏高,大量慢查询,大量并发线程堆积。后面开发对insert的相关业务限流后,服务器性能恢复正常。【异常期间线程处理情况】
【问题】
最近有台服务器比较频繁的CPU报警,表现的特征有CPU sys占比偏高,大量慢查询,大量并发线程堆积。后面开发对insert的相关业务限流后,服务器性能恢复正常。
【异常期间线程处理情况】
下图是当时生产环境异常时抓取的信息,该事务正在执行insert,已经执行5秒,线程运行在innodb内核,状态是thread declared inside InnoDB,还有4906 tickets可用
统计了下有64个线程在innodb层,同时看到还有280个线程在排队等待进入innodb线程,状态是sleeping before entering InnoDB
innodb层的并发线程执行的 SQL 比较慢,产生了阻塞,导致了 mysql 的并发线程堆积。
【哪些SQL执行慢】
从正在执行的SQL中,看到了insert的慢查询SQL语句,统计了下这句SQL批量插入大于342条记录(SQL被截断)
【批量insert的性能测试】
类似这种批量的insert SQL会对MySQL性能造成影响吗,多大的批次比较合理呢,做了下面测试
在测试服务器上新建测试表(表结构同生产环境),并定义了5个插入脚本,分别为单条insert,每10条1个批次insert,每50条1个批次insert,每100条1个批次insert,每340条1个批次insert
用压测 工具 模拟512个并发线程的情况下,不同类型的SQL插入100W条记录服务器的性能情况,下表是压测统计
数据量 |
并发线程 |
执行时间(秒) |
每秒insert |
慢查询数量 |
Context switch |
CPU使用率 |
CPU sys占比 |
|
普通insert(1条) |
1000000 |
512 |
33 |
3W |
0 |
79W |
73% |
39% |
批量SQL(10条) |
1000000 |
512 |
23 |
4.3W |
0 |
49W |
78% |
56% |
批量SQL(50条) |
1000000 |
512 |
21 |
4.7W |
0 |
42W |
80% |
60% |
批量SQL(100条) |
1000000 |
512 |
15 |
6.6W |
20 |
53W |
70% |
45% |
批量SQL(340条) |
1000000 |
512 |
15 |
6.6W |
200 |
38W |
86% |
70% |
下图是批量SQL(340条)执行时的性能情况,可以看到当每100条记录一个批次执行insert时,开始出现慢查询,每340条1个批次执行insert时,在高并发的情况下,会产生大量的慢查询,这个现象接近于我们目前生产环境异常时的情况
【优化方案】
对于MySQL需要插入大量数据时,每次单条的insert性能较差,为了提升insert性能,我们采用了每批次多条记录同时insert的方法。
但当批次增大到一定数量时,在高并发访问的情况下,单个批次执行的性能会出现较大的下降,出现大量慢查询,并发线程堆积,CPU上升出现瓶颈, innodb层的并发线程处理被慢查询阻塞,后面只能通过限流来缓解性能问题。
根据上面的测试结论, 建议控制热表单个批次insert的记录条数,最好单个批次控制在10条左右 (因为即使调大到50条,插入性能没有大的提升,在高并发场景下,首先要保证当前SQL的执行性能)。
【优化后CPU告警消失,运行平稳】
Linux公社的RSS地址 : https://www.linuxidc.com/rssFeed.aspx
本文永久更新链接地址: https://www.linuxidc.com/Linux/2018-10/154981.htm
以上所述就是小编给大家介绍的《MySQL Insert语句单个批次数量过多导致的CPU性能问题分析》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:- 如何在 Azure Lab Services 中批次啟動與停止實驗室中所有虛擬機器 (VMs)
- hibernate多对多,单个修改很伤神
- php取出数组单个值的方法
- 巧断梯度:单个loss实现GAN模型
- Oracle 11g 起停RAC中单个节点
- 后台接收Json请求参数兼容数组和单个对象
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。