从数据库服务器负载飙升100+说起

在生产环境监控中，某核心数据库（Oracle）服务器突然触发严重告警。系统响应极度缓慢，业务连接出现超时。运维人员介入后，通过top命令捕获到了系统处于“假死”状态的关键现场。在处理的过程中发现，不仅是存在业务慢SQL问题，也有透明大页的影响。

一、故障现场分析

通过上面的截图（故障时），我们观察到系统处于极端的资源争抢状态，主要特征如下：

• 系统负载惊人：load average显示为81.27, 101.32, 68.58。这意味着在1分钟内，有超过80个进程在等待CPU资源。对于一台常规的数据库服务器（当前未32核），这个数值意味着系统已经完全瘫痪。
• 诡异的CPU消耗者：在进程列表中，除了多个oracle进程处于R状态且占用99%CPU外，一个名为khugepaged的内核进程赫然在列，且CPU占用率高达76.7%。通常情况下，khugepaged是Linux内核用于管理透明大页的后台线程，其CPU占用率应极低。如此高的占用率极为罕见。
• 内存交换频繁：Swap分区已使用约1.5GB。这表明物理内存吃紧，系统正在频繁地将内存数据交换到磁盘，这不仅消耗IO，也加剧了CPU的上下文切换负担。

二、根因分析

结合现象分析，导致系统雪崩的核心原因不仅仅是单纯的业务量大（慢SQL问题本次就不做赘述了），也与Linux透明大页机制与Oracle数据库的冲突。

1. khugepaged是什么？

khugepaged是Linux内核线程，负责将标准的4KB内存页在后台合并为2MB的透明大页，以提升内存访问效率。

2. 为什么会崩溃？

Oracle数据库拥有自己复杂的内存管理机制。当Linux强制开启透明大页时，khugepaged会不断地扫描Oracle的内存空间（SGA/PGA），试图进行页合并。

死循环效应：Oracle频繁分配释放内存->khugepaged频繁扫描合并->导致极高的CPU消耗（系统态）->导致内存碎片整理->导致业务进程被阻塞。

这解释了为何sy系统态CPU之前很高，且khugepaged单进程吃掉了大量CPU时间片。

三、实施优化

针对上述分析，我们在杀掉慢SQL后立即采取了禁用透明大页的措施。

1. 临时生效（立即执行）

为了避免重启数据库或服务器，直接通过文件系统接口关闭该功能：

# 关闭透明大页的启用状态
echo never > /sys/kernel/mm/transparent_hugepage/enabled
# 关闭透明大页的内存碎片整理（这会直接停止 khugepaged 的频繁扫描和合并工作）
echo never > /sys/kernel/mm/transparent_hugepage/defrag

这一步直接切断了khugepaged的工作源头。

2. 永久生效（配置固化）

修改/etc/rc.local，确保重启后配置依然有效，防止故障复发。修改方法就是在文件末尾（exit 0之前）添加以下内容：

if test -f /sys/kernel/mm/transparent_hugepage/enabled; then
   echo never > /sys/kernel/mm/transparent_hugepage/enabled
fi
if test -f /sys/kernel/mm/transparent_hugepage/defrag; then
   echo never > /sys/kernel/mm/transparent_hugepage/defrag
fi

四、效果验证

实施操作5分钟后，再次采集top信息，系统状态发生了翻天覆地的变化，如图：

1. 负载断崖式下跌

load average从100+降至1.31, 1.79, 6.25。系统彻底恢复了响应能力。

2. khugepaged消失

进程列表中不再显示khugepaged的高CPU占用，系统态CPU(sy)降至0.1%，说明内核不再忙于内存管理杂务。

3. Swap使用量减少

随着内存管理的正常化，Swap使用量从1.5GB降至175MB，系统不再频繁进行磁盘交换。

4. 业务回归正常

虽然仍有一个Oracle进程占用99%CPU，但这属于正常的业务计算（单一会话忙），而非之前的系统级死锁。其他Oracle进程均处于休眠或低负载状态，数据库已能正常服务其他请求。

五、总结

本次故障是典型的操作系统配置不当引发数据库性能灾难的案例。在部署Oracle等内存敏感型数据库时，都建议禁用Linux透明大页。