Linux上MySQL优化提升性能,哪些可以优化关闭NUMA特性?

Linux上MySQL优化提升性能,哪些可以优化关闭NUMA特性?,第1张

Linux上MySQL优化提升性能,可以优化关闭NUMA特性如下:

这些其实都源于CPU最新的技术:节能模式。 *** 作系统和CPU硬件配合,系统不繁忙的时候,为了节约电能和降低温度,它会将CPU降频。

为了保证MySQL能够充分利用CPU的资源,建议设置CPU为最大性能模式。这个设置可以在BIOS和 *** 作系统中设置,当然,在BIOS中设置该选项更好,更彻底。

然后我们看看内存方面,我们有哪些可以优化的。

i)我们先看看numa

非一致存储访问结构(NUMA:Non-UniformMemoryAccess)也是最新的内存管理技术。它和对称多处理器结构(SMP:SymmetricMulti-Processor)是对应的。

我们可以直观的看到:SMP访问内存的都是代价都是一样的但是在NUMA架构下,本地内存的访问和非本地内存的访问代价是不一样的。对应的根据这个特性, *** 作系统上,我们可以设置进程的内存分配方式。目前支持的方式包括:

--interleave=nodes

--membind=nodes

--cpunodebind=nodes

--physcpubind=cpus

--localalloc

--preferred=node

简而言之,就是说,你可以指定内存在本地分配,在某几个CPU节点分配或者轮询分配。除非是设置为--interleave=nodes轮询分配方式,即内存可以在任意NUMA节点上分配这种方式以外。其他的方式就算其他NUMA节点上还有内存剩余,Linux也不会把剩余的内存分配给这个进程,而是采用SWAP的方式来获得内存。

所以最简单的方法,还是关闭掉这个特性。

关闭特性的方法,分别有:可以从BIOS, *** 作系统,启动进程时临时关闭这个特性。

a)由于各种BIOS类型的区别,如何关闭NUMA千差万别,我们这里就不具体展示怎么设置了。

b)在 *** 作系统中关闭,可以直接在/etc/grub.conf的kernel行最后添加numa=off,如下所示:

kernel/vmlinuz-2.6.32-220.el6.x86_64roroot=/dev/mapper/VolGroup-rootrd_NO_LUKS.UTF-8rd_LVM_LV=VolGroup/rootrd_NO_MDquietSYSFONT=latarcyrheb-sun16rhgbcrashkernel=autord_LVM_LV=VolGroup/swaprhgbcrashkernel=autoquietKEYBOARDTYPE=pcKEYTABLE=usrd_NO_DMnuma=off

另外可以设置vm.zone_reclaim_mode=0尽量回收内存。

c)启动MySQL的时候,关闭NUMA特性:

numactl--interleave=allmysqld

当然,最好的方式是在BIOS中关闭。

ii)我们再看看vm.swappiness。

vm.swappiness是 *** 作系统控制物理内存交换出去的策略。它允许的值是一个百分比的值,最小为0,最大运行100,该值默认为60。vm.swappiness设置为0表示尽量少swap,100表示尽量将inactive的内存页交换出去。

具体的说:当内存基本用满的时候,系统会根据这个参数来判断是把内存中很少用到的inactive内存交换出去,还是释放数据的cache。

先 找到 CPU 高的线程,如果 CPU 高的线程号一直在变,那可能不是单个 SQL 引起的 CPU 消耗,需要用其他方法来辅助分析。找到线程任务processlist 。

可以看到很多有用的信息:

1. 可以看到 processlist 中对应这根线程的信息

2. 可以找到其在 processlist 中的 ID,这样我们就可以下 kill 命令来结束 SQL

小贴士:

使用 performance_schema 时,需要大家注意 MySQL 使用了多个线程编号,源自于不同视角:

1. PROCESSLIST_ID:在 processlist 中的编号,是使用者视角的编号,使用者可以直接用 kill 命令。

2. THREAD_ID:是 MySQL 内部使用的线程编号,是 MySQL 内部视角的编号。

3. THREAD_OS_ID:是在 *** 作系统上,对应的线程编号,是 *** 作系统视角的编号。

大家使用时需要区分好,不要 kill 错了 SQL。

其他有用的信息,可以看到 SQL 执行的开始时间,正在使用了一张临时磁盘表。

如果开启了 performance_schema 的其他监控项,通过 Thread_ID 关联,可以找到更多信息。

当然,眼下这么明显的坑 SQL,我们 kill 掉就是了。


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zaji/6097258.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-03-14
下一篇 2023-03-14

发表评论

登录后才能评论

评论列表(0条)

保存