MySQL 5.6 信号量争用 row0purge.cc dict0dict.cc答案

【问题标题】：MySQL 5.6 Semaphore Contention row0purge.cc dict0dict.ccMySQL 5.6 信号量争用 row0purge.cc dict0dict.cc
【发布时间】：2016-03-10 22:30:14
【问题描述】：

服务器详情

MySQL 5.6.22
256GB 内存
4TB SSD
32 核

背景信息

有一个删除过程每秒执行大约 3 次删除。每秒 2-3k QPS。主要是选择。没有长时间运行的查询。

问题

有时，查询会在 1-3 秒范围内开始运行，而不是毫秒。其中大部分处于“等待查询缓存锁”。

SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count -2033262178
--Thread 6060 has waited at row0purge.cc line 754 for 1.00 seconds the semaphore:
S-lock on RW-latch at 00007FF62B1C9F60 created in file dict0dict.cc line 983
a writer (thread id 9580) has reserved it in mode  exclusive
number of readers 0, waiters flag 1, lock_word: 0
Last time read locked in file row0purge.cc line 754
Last time write locked in file ..\..\..\mysqlcom-pro-5.6.22\storage\innobase\row\row0mysql.cc line 3838
--Thread 5204 has waited at row0purge.cc line 754 for 1.00 seconds the semaphore:
S-lock on RW-latch at 00007FF62B1C9F60 created in file dict0dict.cc line 983
a writer (thread id 9580) has reserved it in mode  exclusive
number of readers 0, waiters flag 1, lock_word: 0
Last time read locked in file row0purge.cc line 754
Last time write locked in file ..\..\..\mysqlcom-pro-5.6.22\storage\innobase\row\row0mysql.cc line 3838
--Thread 5556 has waited at row0purge.cc line 754 for 1.00 seconds the semaphore:
S-lock on RW-latch at 00007FF62B1C9F60 created in file dict0dict.cc line 983
a writer (thread id 9580) has reserved it in mode  exclusive
number of readers 0, waiters flag 1, lock_word: 0
Last time read locked in file row0purge.cc line 754
Last time write locked in file ..\..\..\mysqlcom-pro-5.6.22\storage\innobase\row\row0mysql.cc line 3838
--Thread 6112 has waited at row0purge.cc line 754 for 1.00 seconds the semaphore:
S-lock on RW-latch at 00007FF62B1C9F60 created in file dict0dict.cc line 983
a writer (thread id 9580) has reserved it in mode  exclusive
number of readers 0, waiters flag 1, lock_word: 0
Last time read locked in file row0purge.cc line 754
Last time write locked in file ..\..\..\mysqlcom-pro-5.6.22\storage\innobase\row\row0mysql.cc line 3838
--Thread 5868 has waited at dict0dict.cc line 1037 for 1.00 seconds the semaphore:
Mutex at 000000279A10EDA8 created file dict0dict.cc line 974, lock var 1
waiters flag 1
--Thread 5236 has waited at buf0flu.cc line 2077 for 0.00 seconds the semaphore:
Mutex at 00000000345B7F68 created file buf0buf.cc line 1270, lock var 1
waiters flag 1
OS WAIT ARRAY INFO: signal count -1213535755
Mutex spin waits 8166969384, rounds 34032056620, OS waits 750640991
RW-shared spins 3891056500, rounds 50813966471, OS waits 764118585
RW-excl spins 9963649634, rounds 77579501565, OS waits 718551543
Spin rounds per wait: -80.46 mutex, -125.80 RW-shared, 56.47 RW-excl

问题

我想知道可能是什么原因。我会理解它是否是一致的，因为 DELETE 过程正在进行中，但它非常零星。与 dict0dict.cc 和 row0purge.cc 相关的信号量让我假设它与导致争用的 DELETES 相关。对此有任何想法都会很棒。

【问题讨论】：

标签： mysql performance semaphore mysql-5.6 contention

【解决方案1】：

查询缓存锁定意味着与查询缓存存在争用，似乎删除 SQL 正在使查询缓存失效。通常我会关闭查询缓存以避免此类问题。请尝试禁用查询缓存。

【讨论】：

是的，查询缓存是一个争论点，但在这种情况下它的优点多于缺点。将其关闭将是一个更大的问题。我的问题与信号量以及这些源文件与什么有关。
至少保持query_cache_size 每个 DELETE），它必须扫描整个QC，看看有什么需要净化。更大 == 更慢。
感谢@RickJames 我刚刚将大小从 256M 更改为 100M。我会等着看缓存实际填满了多少，看看我能不能再降低一点。
SHOW GLOBAL STATUS LIKE 'Qc%'; 和SHOW VARIABLES LIKE 'query%'; 提供了一些神秘的线索。
@RickJames 只是一些早期的观察.. 我注意到一些单行插入现在需要超过一秒钟。 innodb_max_dirty_pages_pct 设置为 50