背景：
公司某个大型业务系统反馈最近数据库服务器总是宕机（此处描述不准确，后面解释），最后，客户、运维人员都觉得实在是忍无可忍了，项目经理打电话找到我问是否能帮忙诊断一下，刚好第二天要去现场沟通另外一个系统的测试需求，于是答应第二天顺便看一下。
------------------------------------
排查解决过程：
第二天来到现场，正在沟通需求的时候，运维人员突然说，操作又开始卡了，
于是连上服务器，先用top大概看了一下资源的使用情况，此时CPU已经基本上满载了，而且可以发现用户态的CPU占比并不高，大部分时间竟然都是内核态的CPU占用，
当时我开始怀疑可能是数据库服务对底层的某个调用出了问题，有死循环？
于是立刻用perf top大概看了一下，
发现比重较大的是自旋锁还有一个compaction_alloc，内存碎片整理？
从该信息判断，可能是内存的什么操作导致了很多线程在临界区各种等待。
为了进一步弄明白具体是什么操作导致，于是对内核参数的调用栈进行取样
perf record -a -g -F 1000 sleep 60
“-g‘的意思是按照调用关系存储数据；“-F 1000 sleep 60”表示按照每秒取1000个样本的频率取一分钟。
取完样后，使用perf report -g打开取样的数据，可以看到如下的调用栈：
很明显这个自旋锁是由内存页的碎片整理导致，而进行碎片整理是由hugepage导致的，
看到这里的时候，我突然想起来linux的一个THP特性，貌似是kelnel 2.6.38版本后开始加进来的，
这个特性实际上就是会把这种巨页的使用对用户透明，用户不需要再进行巨页的配置，
内存会自动将连续的512个普通页作为一个巨页处理，
正如我们在前面的调用栈看到的，这种特性就需要对内存碎片进行整理，
所以我们看到的现象是内存碎片页移动导致的自旋锁，而根本原因是THP特性所导致的。
知道了问题原因，解决也就容易了，只要把THP关闭就可以了。
关闭的方法如下：
vi /etc/rc.local
在文件末尾添加如下指令：
if test -f /sys/kernel/mm/redhat_transparent_hugepage/enabled; then
echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled
fi
if test -f /sys/kernel/mm/redhat_transparent_hugepage/defrag; then
echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag
fi
保存后，重启即可。
PS：此处不同版本的linux路径会有些区别，自己看好了
vi /sys/kernel/mm/redhat_transparent_hugepage/enabled
如果显示如下：
即为关闭THP生效。
其实这样做完还不算完全解决问题，就如我们前面说的，
THP的引入是为了减少维护人员配置巨页的工作，我们把THP特性关掉了，
最好的实践是我们应该再根据我们数据库服务需要的共享内存大小进行hugepage的配置。
毕竟在现在动辄几十G，甚至上百G的内存，如果在按照4K普通页大小去维护TLB，也是一个很大的开销。
这里hugepage的配置，因为数据库不同，甚至数据库版本不同，配置过程也不大相同，最重要的一点，我发现这篇日志写的有点太长了。
因此，这里就不展开赘述了，有时间可以开帖讲一讲。
-----------------------------------------------
解决效果：
在进行如上两步处理后，连续观察了几天，果然再没有所谓的“宕机”事件了。
这里“宕机”用了引号，对应最前面反馈问题时项目经理所说的服务器宕机描述，其实这个描述本身就是错误的，明天我准备再针对这个详细解释一下：如何正确的提问。
具体操作:如何将Transparent HugePages关闭
reference:https://blog.csdn.net/scofy0/article/details/43270517
