我们有一个应用程序(在 Amazon RDS MySQL 5.7 上db.m5.24xlarge
;96 个内核),它在并行处理器+队列中接收大量数据。它主要用于一张表,主键不分布在多个队列中。条目在事务中批量处理。
当我们增加处理器+队列的数量时,会有一个临界点,所有的等待时间都花在了wait/synch/mutex/innodb/lock_mutex
,但我真的找不到这意味着什么。它甚至需要 CPU 周期,所以这些是自旋锁互斥锁?
性能洞察:
我已经禁用了不推荐使用的查询缓存和自适应哈希索引,因为它们都是互斥锁管理的,无助于我们INSERT ON DUPLICATE KEY UPDATE
繁重的工作量。
那么,由 管理的资源是什么wait/synch/mutex/innodb/lock_mutex
,我是否可以通过设置或使用较低的事务隔离级别来控制它?
编辑:
show engine innodb status
显示:
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 10591578
--Thread 47139002062592 has waited at lock0lock.cc line 6415 for 0 seconds the semaphore:
Mutex at 0x2b2be1000058, Mutex LOCK_SYS created lock0lock.cc:454, lock var 1
wait has ended
--Thread 47138574509824 has waited at lock0lock.cc line 6415 for 0 seconds the semaphore:
Mutex at 0x2b2be1000058, Mutex LOCK_SYS created lock0lock.cc:454, lock var 1
wait has ended
--Thread 47136822810368 has waited at lock0lock.cc line 6342 for 0 seconds the semaphore:
Mutex at 0x2b2be1000058, Mutex LOCK_SYS created lock0lock.cc:454, lock var 1
wait has ended
--Thread 47137720436480 has waited at lock0lock.cc line 6342 for 0 seconds the semaphore:
Mutex at 0x2b2be1000058, Mutex LOCK_SYS created lock0lock.cc:454, lock var 1
and many more
编辑:在MySQL 8 changelog中也很有趣,它说:
InnoDB:为了提高需要访问表和行资源的锁队列的操作的并发性,锁系统互斥锁(lock_sys->mutex)被分片锁存器取代,锁队列被分组为表和页锁队列分片,每个由专用互斥锁保护的分片。以前,单锁系统互斥锁保护所有锁队列,这是高并发系统上的一个争论点。新的分片实现允许对锁队列进行更精细的访问。
那我会受到影响吗?我只需要执行“快速”升级...
本次提交中引入了分片锁系统。
他们有很好的提交消息,这解释了 lock-sys 是什么(这是我最初的问题):
因此,除了减少并发性之外,这不是您作为用户可以控制的任何事情。
在 MySQL 8 上测试运行系统显示了显着的改进:
在 96 核 MySQL 服务器上,这些是 64 个队列处理器(=64 个进程)在同一个表上运行,但都在不同的行上(主要是更新)。您可以看到,除了 CPU 和 SQL 处理之外,不再有互斥等待状态,这很好。