简单说说THP——记一次数据库服务器阻塞的问题解决

简单说说THP——记一次数据库服务器阻塞的问题解决

情况:
某企业大中型业务管理系统反馈最近数据库查询网络服务器已宕机(此处描述不准确，后面再描述)。最后客户和运维管理人员都觉得是真的。项目经理打电话给，问我是否能帮忙诊断一下。恰好第二天他要去现场沟通另一个系统软件的测试需求，于是同意第二天去看一下。
-


所以，当你连接到网络服务器的时候，用top看看资源的应用状态。此时大部分CPU都已经加载完毕，你可以发现客户端状态的CPU份额并不高，大部分时间其实都是被核心状态的CPU占用的。

当时我就开始怀疑，可能是数据库查询服务项目最低调用有问题，出现了死循环？
所以我马上用perftop来看看，

发现自旋锁也有compaction_alloc，内存碎片整理？
从这些信息的内容可以看出，内存的实际 *** 作可能导致了线程同步在临界区等待。
为了进一步了解实际 *** 作，对核心主要参数的调用栈进行采样
perfrecord-a-g-f1000sleep60
-g”表示根据调用关联存储数据信息；“-F1000sleep60”就是按照每秒取1000个样本的频率取一分钟。
采样后，应用perfreport-g打开采样的数据信息，可以看到如下调用栈:

很明显，这个自旋锁是内存页碎片整理造成的，而碎片整理是hugepage造成的。
看到这里，我突然想起了linux的一个THP特性，好像是在Kelnel2.6.38版本之后才开始的，
。客户不再需要分配巨型页面。
内存会自动将持久化的512个通用页面解析为一个巨页。
正如我们在前面的调用栈中看到的，这种特性必须整理内存碎片。
所以，你看到的是内存碎片页移动造成的自旋。
知道了问题的原因，处理起来就很容易了。关掉THP。
关闭如下:
vi/etc/rc.local
在文档末尾添加以下命令:
iftest-f/sys/kernel/mm/redhat_transparent_hugepage/enabled；那么
echonever>；/sys/kernel/mm/redhat_transparent_hugepage/enabled
fi
iftest-f/sys/kernel/mm/redhat_transparent_hugepage/defrag；那么
echonever>；/sys/kernel/mm/redhat_transparent_hugepage/defrag
fi

保存后重启即可。
PS:这里不同版本号的linux做法会有一些差异。我喜欢

VI/sys/kernel/mm/redhat_transparent_hugepage/enabled
如果显示以下信息:[

也就是说，关掉THP作品。实际上，那并不能完全解决困难。前面大家都说了，
THP的引入是为了更好的减轻维护人员的工作。每个人都关掉了THP的功能。
最好的做法是每个人都以你为榜样。
毕竟现在的它，需要几十甚至上百兆的内存。如果按照4k高清的一般页面大小来维护TLB，也是一笔非常大的开销。
在这里，hugepage配备了不同的数据库查询，甚至不同的数据库查询版本号。整个装备的过程是不一样的。最重要的一点是，我发现这个日志有点太长了。
所以，这里不做过多解释。有空可以开个帖子说说。
-[/S2/]
这里用了一个冒号来表示“服务器停机”，与工程项目经理常说的出现前置反馈问题时的停机叙事相吻合。事实上，这种叙述本身是不正确的。明天我会提前准备讲解这个细节:如何正确提问。