Ade*_*ard 15 mysql innodb buffer-pool
哪个更好:
因此,我不确定如何推理缓冲池实例以及整个“在拥有如此大的 InnoDB 缓冲池大小时使用实例或遭受操作系统交换”。
当我回到 MySQL 5.5 时,我会考虑同样的事情。
这些年来我学到的是:如果缓冲池大于已安装 RAM 的一半并且innodb_buffer_pool_instances为 1(默认为 5.5),则交换的威胁总是迫在眉睫。
我之前讨论过这个问题:是否有关于缓冲池实例的大小和数量的经验法则?. 在那篇文章中,我提到了一个客户端的示例,该客户端在服务器上具有 192GB RAM 和 162GB 缓冲池。当innodb_buffer_pool_instances为 1 时,发生交换。当我将innodb_buffer_pool_instances设置为 2 时,事情变得更好了。
在您的情况下,由于缓冲池正好是一半,因此值 1 可能没问题。我不会冒险的。我会把它设置为 2。
由于 MySQL 5.6 的默认值为 8,因此您不必再考虑它了。
我会这样说:akuzminsky 的回答具有最高原则。我的答案只是根据过去的经验(好与坏)从臀部拍摄。
应增加缓冲池实例的数量以避免缓冲池互斥量争用。
缓冲池大小为 8GB 时,我怀疑您永远不会看到缓冲池互斥量争用。
更新 0:
我在答案中提到了 8Gb 缓冲池,而在原始问题中,总内存为 8GB。当然,缓冲池必须小于 8GB。4GB 听起来是个不错的开始,但请确保不会发生交换。
更新 1:
// 来自Yasufumi 的幻灯片(在最近的 MySQL 版本中,输出可能略有不同)
要确定缓冲池互斥锁是否存在争用,请SHOW ENGINE INNODB STATUS
在高峰时间收集十几个样本。
然后使用 shell 片段聚合它:
#!/bin/sh
cat $1.innodb | grep "Mutex at " | cut -d"," -f1 | sort | uniq -c > /tmp/tmp1.txt
cat $1.innodb | grep "lock on " | cut -d"-"
-f2- | sort | uniq -c > /tmp/tmp2.txt
cat /tmp/tmp1.txt /tmp/tmp2.txt | sort -n > $1.contention rm /tmp/tmp1.txt /tmp/tmp2.txt
Run Code Online (Sandbox Code Playgroud)
它给出了这样的输出:
.....
4 lock on RW-latch at 0x7fb86b2c9138 created in file dict/dict0dict.c line 1356
6 lock on RW-latch at 0x7fb86b2c4138 created in file dict/dict0dict.c line 1356
12 lock on RW-latch at 0x7fb86b2d9538 created in file dict/dict0dict.c line 1356
20 lock on RW-latch at 0x7fb86b2db138 created in file dict/dict0dict.c line 1356
22 Mutex at 0x7fb86b28f0e0 created file btr/btr0sea.c line 139
30 lock on RW-latch at 0x7fb86b2ba938 created in file dict/dict0dict.c line 1356
36 lock on RW-latch at 0x7fb86b2bad38 created in file dict/dict0dict.c line 1356
71 Mutex at 0x7fb86b28ecb8 created file buf/buf0buf.c line 597
164 lock on RW-latch at 0x7fb86b28f0b8 created in file btr/btr0sea.c line 139
Run Code Online (Sandbox Code Playgroud)
如果您看到大量缓冲池互斥等待,那么是时候考虑多个缓冲池实例了。在小于 ~48G 的缓冲池上不太可能发生争用。