你双 CPU 的话主要排查方向就是 NUMA 。建议先确定每个 CPU 配了多少内存、PCIE 上挂了哪些设备。比如你数据库需要 20GB ,然后你是两个 CPU 各配了 10GB ,那么很多查询都需要走总线去另一个 CPU 去读内存,能快就怪了。我还见过内存全装到了一个 CPU ,这样另一个 CPU 等于是减速器。
另外 6133 是个 Skylake 代的 CPU ,属于需要的硬件漏洞补丁特别多,可以临时加一个 mitigations=off 内核命令看一下性能有没有改善。如果是这个原因那就考虑升级 Cpu 。
你双 CPU 的话主要排查方向就是 NUMA 。建议先确定每个 CPU 配了多少内存、PCIE 上挂了哪些设备。比如你数据库需要 20GB ,然后你是两个 CPU 各配了 10GB ,那么很多查询都需要走总线去另一个 CPU 去读内存,能快就怪了。我还见过内存全装到了一个 CPU ,这样另一个 CPU 等于是减速器。
另外 6133 是个 Skylake 代的 CPU ,属于需要的硬件漏洞补丁特别多,可以临时加一个 mitigations=off 内核命令看一下性能有没有改善。如果是这个原因那就考虑升级 Cpu 。最后这是个核密集型号,这种的目标客户是虚拟化。对于关系型数据库你需要找核数少,主频特别高的。
另外 6133 是个 Skylake 代的 CPU ,属于需要的硬件漏洞补丁特别多,可以临时加一个 mitigations=off 内核命令看一下性能有没有改善。如果是这个原因那就考虑升级 Cpu 。
最后这是个核密集型号,这种的目标客户是虚拟化。对于关系型数据库你需要找核数少,主频特别高的。
(base) root@ubuntu:~# dd bs=64k count=4k if=/dev/zero of=test oflag=dsync
4096+0 records in
4096+0 records out
268435456 bytes (268 MB, 256 MiB) copied, 2.70439 s, 99.3 MB/s
另外 6133 是个 Skylake 代的 CPU ,属于需要的硬件漏洞补丁特别多,可以临时加一个 mitigations=off 内核命令看一下性能有没有改善。如果是这个原因那就考虑升级 Cpu 。最后这是个核密集型号,这种的目标客户是虚拟化。对于关系型数据库你需要找核数少,主频特别高的。
4K IO 的指标也很重要
2.对比 MySQL 版本
3.对比 MySQL 参数,例如相关 buffer 的参数值