主题
生产故障深度排查：CPU Load 与时间偏移疑难案例
两个看似无关、实则同源的经典生产疑难场景。覆盖 Linux 内核调度、时钟源、D 状态进程、NMI watchdog 等底层原理，配套可直接执行的排查命令和解决方案。
场景一：CPU 使用率低、CPU Load 高
1.1 问题现象
监控显示：
- CPU 使用率（user + sys）：仅 10%-20%
- CPU Load Average：持续 > CPU 核数（如 8 核机器 load 达到 30-50）
- top 中看不到高 CPU 的进程
- 应用响应变慢，偶发超时1.2 核心原理：Load Average 的真实含义
很多人误解 Load Average = CPU 繁忙程度，这是错误的。
Load Average 的真实定义（Linux 特有）：
= 正在运行的进程数（R 状态）
+ 等待运行的进程数（runnable）
+ 处于不可中断睡眠的进程数（D 状态） ← 这是关键！
Linux 的 Load Average 与 Unix 的区别：
- 传统 Unix：只计算 R + runnable
- Linux：额外计算 D 状态（TASK_UNINTERRUPTIBLE）
所以 Linux 的 Load Average 高 ≠ CPU 忙
Linux Load 高 = 有进程在等待（CPU 或 I/O）D 状态进程（TASK_UNINTERRUPTIBLE）：
D 状态的特征：
- 进程不可被信号中断（连 kill -9 都杀不掉）
- 通常是等待内核锁（如磁盘 I/O、NFS、semaphore）
- 贡献到 Load Average，但不消耗 CPU
- 大量 D 状态进程 = Load 高 + CPU 使用率低
常见产生 D 状态的场景：
1. NFS 服务端无响应（mount 点卡死）
2. 磁盘 I/O 超时（坏盘、RAID 降级、存储链路抖动）
3. 文件系统元数据操作阻塞（大目录 ls、inode 耗尽）
4. 内核锁竞争（mm_sem、i_mutex）
5. FUSE 文件系统卡死
6. iSCSI/FC 存储链路中断1.3 系统化排查步骤
bash
# === 第一步：确认 D 状态进程数量 ===
ps aux | awk '$8 ~ /D/' | wc -l
# 或者更精确：
ps -eo state,pid,cmd | grep '^D'
# === 第二步：查看 D 状态进程在等什么 ===
ps aux | awk '$8 ~ /D/'
# 关注 WCHAN 列（等待的内核函数）
# 常见 WCHAN：
# - nfs_wait_bit_killable → NFS 卡死
# - io_schedule → 磁盘 I/O 等待
# - rpc_wait_bit_killable → RPC 调用卡死
# - wait_on_page_bit → 页面缓存 I/O
# === 第三步：查看每个 D 进程的调用栈 ===
for pid in $(ps -eo state,pid | awk '$1=="D"{print $2}'); do
echo "=== PID $pid ==="
cat /proc/$pid/stack 2>/dev/null | head -5
cat /proc/$pid/wchan 2>/dev/null
echo
done
# === 第四步：检查 I/O 状况 ===
iostat -x 1 5 # 查看 %util、await、r_await、w_await
# %util > 95% → 磁盘饱和
# await > 100ms → I/O 延迟异常
# r_await 高 → 读 I/O 阻塞（可能是 NFS）
# === 第五步：检查 NFS 挂载点 ===
mount | grep nfs
# 尝试访问每个 NFS 挂载点（可能卡死）：
timeout 3 ls /mnt/nfs-share 2>&1
# 如果卡住 → 该 NFS 服务端无响应
# === 第六步：查看内核日志 ===
dmesg -T | tail -50
# 关注：
# - "task xxx blocked for more than 120 seconds"
# - "hung_task" 警告
# - "nfs: server xxx not responding"
# - "I/O error" / "medium error"
# - "EXT4-fs error" / "XFS error"
# === 第七步：检查中断和软中断 ===
cat /proc/interrupts | head -20
watch -n 1 cat /proc/interrupts # 观察中断增量
# 如果某个中断（如 eth0）不增长 → 网卡/驱动问题1.4 解决方案（按根因分类）
根因 A：NFS 挂载点卡死
bash
# 紧急恢复：强制卸载卡死的 NFS
umount -f -l /mnt/nfs-share # -l = lazy umount，立即从 namespace 中移除
# 长期方案：挂载时加 timeout 参数
# /etc/fstab 示例：
# nfs-server:/share /mnt/nfs nfs defaults,soft,timeo=30,retrans=2,tcp 0 0
#
# 参数解释：
# soft → I/O 超时后返回错误（而非无限等待）
# timeo=30 → 超时时间 3 秒（单位 0.1 秒）
# retrans=2 → 最多重试 2 次
#
# ⚠️ 注意：soft 模式可能导致应用收到 I/O 错误，需要应用层处理
# 生产推荐：hard + intr + timeo=60（hard 保证数据一致，intr 允许信号中断）
# 监控 NFS 响应时间
nfsstat -c # 客户端统计
nfsiostat 1 5 # 每秒刷新根因 B：磁盘 I/O 饱和
bash
# 诊断：
iostat -xz 1
# 关注：%util（利用率）、await（平均延迟）、avgqu-sz（队列深度）
# 找出 I/O 最大的进程：
iotop -oP # 只显示有 I/O 的进程
# 或：
pidstat -d 1 5 # 每进程的 I/O 统计
# 解决：
# 1. 升级磁盘（HDD → SSD/NVMe）
# 2. 分离 I/O 密集型应用到独立磁盘
# 3. 调整 I/O 调度器：
echo mq-deadline > /sys/block/sda/queue/scheduler
# 4. 调整内核参数：
sysctl -w vm.dirty_ratio=10 # 脏页占内存比例上限
sysctl -w vm.dirty_background_ratio=5 # 后台刷脏页阈值根因 C：内核锁竞争 / 文件系统元数据阻塞
bash
# 查看系统级 hung task：
cat /proc/sys/kernel/hung_task_timeout_secs # 默认 120 秒
# 调整检测阈值（更早发现）：
echo 30 > /proc/sys/kernel/hung_task_timeout_secs
echo 1 > /proc/sys/kernel/hung_task_panic # 生产慎用，会 panic
# 查看锁竞争：
perf lock record -a sleep 10
perf lock report
# 文件系统层面：
# 大目录操作（如 ls 百万文件）会导致长时间 D 状态
# 解决：使用 find -maxdepth 1 分批处理，或改用 B-tree 型文件系统（XFS）1.5 真实生产案例
案例：某 RKE2 集群 worker 节点（32 核 128G）
现象：
- CPU 使用率 12%，Load Average 持续 80+
- 大量 Pod 健康检查超时
- 应用响应延迟 5-10 秒
排查过程：
1. ps aux | awk '$8~/D/' → 发现 60+ 个 D 状态进程
2. cat /proc/`<pid>`/stack → 全部卡在 nfs_wait_bit_killable
3. mount | grep nfs → 发现 /data 是 NFS 挂载
4. timeout 3 ls /data → 卡死超时
5. NFS 服务端日志：存储后端磁盘故障，I/O 延迟 > 30 秒
根因：NFS 后端存储磁盘故障，所有访问 /data 的进程进入 D 状态
修复：
1. 紧急：umount -l /data（lazy umount 立即恢复进程）
2. 短期：修复 NFS 后端磁盘
3. 长期：改用 Ceph RBD（分布式存储，无单点故障）场景二：CPU 低、Load 低、但时间偏移 >3 分钟 + 监控断点 + 堡垒机登录失败
2.1 问题现象
这是一组极具迷惑性的症状组合：
监控显示（监控本身也有断点！）：
- CPU 使用率：正常（10%-30%）
- CPU Load：正常（< CPU 核数）
- 内存使用率：正常
- 磁盘 I/O：正常
- 网络流量：正常
但伴随症状：
❌ 时间同步偏移 > 3 分钟（chrony/ntpd 报警）
❌ 监控数据出现间隔缺失（Prometheus 采集断点）
❌ 堡垒机 SSH 登录失败（超时或被拒绝）
❌ 应用偶尔出现超时
❌ dmesg 中出现 "NMI watchdog" 或 "clocksource" 相关告警
关键特征：所有症状同时出现，且监控数据本身也有断点2.2 核心原理：这不是普通问题，是内核级故障
这组症状指向一个共同的根因：
┌───────────────────────────────────────────────────────────┐
│ CPU 核心硬锁定（Hard Lockup） │
│ 或 TSC 时钟源不稳定 │
├───────────────────────────────────────────────────────────┤
│ │
│ CPU 某个核心被"卡住"，无法响应中断和调度 │
│ │
│ 表现： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 1. 时间偏移：CPU 内部时钟计数器（TSC）不稳定 │ │
│ │ → 内核切换到 HPET/acpi_pm → 精度下降 → 时间漂移 │ │
│ │ │ │
│ │ 2. 监控断点：监控 Agent 运行在卡住的 CPU 核心上 │ │
│ │ → Agent 无法被调度 → 无法上报指标 → 数据缺失 │ │
│ │ │ │
│ │ 3. SSH 登录失败：sshd 进程或认证模块被调度到 │ │
│ │ 卡住的核心 → 无法响应 → 登录超时 │ │
│ │ │ │
│ │ 4. CPU 使用率/Load 正常： │ │
│ │ 因为只有 1-2 个核心卡住，其他核心正常工作 │ │
│ │ top 显示的是全局平均值，掩盖了单核问题 │ │
│ └─────────────────────────────────────────────────────┘ │
└───────────────────────────────────────────────────────────┘TSC（Time Stamp Counter）与时钟源：
Linux 时钟源层级：
1. TSC（Time Stamp Counter）
- CPU 内部硬件计数器，每个时钟周期递增
- 精度最高（纳秒级），性能最好
- 问题：不同 CPU 核心的 TSC 可能不同步（SMP TSC drift）
- 问题：CPU 变频/休眠时 TSC 可能停止或跳变
- 问题：虚拟机中 TSC 可能被 hypervisor 错误处理
2. HPET（High Precision Event Timer）
- 主板上的硬件定时器
- 精度较高（微秒级），但有访问延迟
3. acpi_pm
- ACPI 电源管理定时器
- 精度一般，但最稳定
4. jiffies
- 内核软件定时器
- 精度最低（毫秒级），最后手段
当 TSC 被检测到不稳定时：
内核自动切换时钟源：TSC → HPET 或 acpi_pm
切换瞬间 → 时间跳变（可能偏移数秒到数分钟）
新时钟源精度低 → 时间逐渐漂移
NTP/chrony 尝试修正 → 但修正速度跟不上漂移速度NMI Watchdog 与 Hard Lockup：
NMI Watchdog 机制：
- 每个 CPU 核心有一个 NMI（不可屏蔽中断）看门狗
- 定期检查：该核心是否在 10 秒内响应了中断？
- 如果超过 watchdog_thresh（默认 10 秒）无响应：
→ 记录 "watchdog: BUG: soft lockup - CPU#X stuck for Ys!"
→ 或 "watchdog: Watchdog detected hard LOCKUP on cpu X"
Soft Lockup vs Hard Lockup：
Soft Lockup：
- CPU 核心在执行内核代码，但无法调度其他进程
- 通常是内核代码 bug（如死循环、锁竞争）
- 中断可以响应
Hard Lockup：
- CPU 核心完全无响应（连中断都不响应）
- 通常是硬件问题（CPU 故障、BIOS bug、电源问题）
- 中断也无法响应
- 更严重，通常需要重启
为什么 CPU 使用率和 Load 看不出来？
- Hard Lockup 只影响 1-2 个核心
- 其他核心正常工作
- top/htop 显示全局平均值
- 被卡住的核心不计入 CPU 使用率（因为它"不工作"）2.3 系统化排查步骤
bash
# === 第一步：检查内核日志（最关键！） ===
dmesg -T | grep -iE 'lockup|tsc|clocksource|nmi|mce|hardware error' | tail -50
# 典型输出示例：
# [Thu Aug 24 10:23:45 2026] clocksource: Switched to clocksource hpet
# [Thu Aug 24 10:23:46 2026] tsc: Marking TSC unstable due to check_tsc_sync_source failed
# [Thu Aug 24 10:24:15 2026] watchdog: BUG: soft lockup - CPU#7 stuck for 23s!
# [Thu Aug 24 10:25:30 2026] watchdog: Watchdog detected hard LOCKUP on cpu 3
# [Thu Aug 24 10:26:00 2026] mce: [Hardware Error]: Machine check events logged
# === 第二步：检查当前时钟源 ===
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
# 正常应该是：tsc
# 如果变成：hpet 或 acpi_pm → TSC 已切换，时间精度下降
# 查看所有可用时钟源：
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
# === 第三步：检查每个 CPU 核心的状态 ===
# 查看 CPU 在线状态：
cat /sys/devices/system/cpu/cpu*/online 2>/dev/null | head -20
# 0 表示该核心已离线（可能被内核隔离）
# 查看每个核心的中断和软中断增量：
for f in /proc/irq/*/smp_affinity_list; do echo "$f: $(cat $f)"; done | head -20
cat /proc/softirqs | awk 'NR<=12{print}'
# === 第四步：检查 MCE（Machine Check Exception） ===
mcelog --client 2>/dev/null || journalctl -k | grep -i mce | tail -20
# MCE 是硬件错误的直接证据
# === 第五步：检查时间同步状态 ===
chronyc tracking
# 关注：
# Reference ID : 当前时间源
# System time : 与时间源的偏差
# RMS offset : 均方根偏移（> 1秒 = 严重）
chronyc sources -v
# === 第六步：检查 NMI watchdog 配置 ===
cat /proc/sys/kernel/nmi_watchdog
cat /proc/sys/kernel/hung_task_timeout_secs
cat /proc/sys/kernel/softlockup_thresh
# === 第七步：准备抓取 lockup 调用栈 ===
echo 1 > /proc/sys/kernel/softlockup_all_cpu_backtrace
# 下次 soft lockup 时会记录所有 CPU 的完整调用栈
# 配置 kdump（hard lockup 时自动生成 vmcore）：
# yum install kexec-tools crash
# systemctl enable kdump
# 分析：crash vmlinux /var/crash/`<ts>`/vmcore
# crash> bt -a # 查看所有 CPU 调用栈2.4 解决方案（按根因分类）
根因 A：TSC 时钟源不稳定
bash
# 诊断确认：
dmesg -T | grep -i 'tsc.*unstable\|clocksource.*switch'
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
# 临时修复：强制切回 TSC（如果硬件支持）
echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource
# 永久修复：内核启动参数
# 编辑 /etc/default/grub
# GRUB_CMDLINE_LINUX 中添加：
# clocksource=tsc # 强制使用 TSC
# tsc=reliable # 标记 TSC 为可靠（跳过校验）
# -- 或者 --
# clocksource=hpet # 如果 TSC 确实不可靠，强制使用 HPET
# 然后：grub2-mkconfig -o /boot/grub2/grub.cfg
# 时间修正：
chronyc makestep # 立即步进修正时间
# 或：
systemctl restart chronyd
# 预防措施：
# 1. BIOS 中关闭 C-States（C1E, C6 等 CPU 节能状态）
# 这些状态可能导致 TSC 在休眠时停止
# 2. BIOS 中关闭 CPU 变频（SpeedStep/Turbo Boost）
# 变频可能导致 TSC 频率变化
# 3. 虚拟机确保 hypervisor 提供 invariant TSC
# VMware: tsc.scale = "TRUE"
# KVM: 确保 CPU model 为 host-passthrough根因 B：CPU 核心 Hard Lockup（硬件故障）
bash
# 确认哪个核心有问题：
dmesg -T | grep -i 'lockup.*cpu'
# 输出示例：watchdog: Watchdog detected hard LOCKUP on cpu 7
# 临时措施：隔离问题核心
# 将问题核心离线（online = 0）：
echo 0 > /sys/devices/system/cpu/cpu7/online
# 注意：这不会修复根因，但可以让系统继续运行
# 确认核心已离线：
cat /sys/devices/system/cpu/cpu7/online # 应该输出 0
# 永久隔离：通过内核参数
# GRUB_CMDLINE_LINUX 中添加：
# maxcpus=N # 限制最大 CPU 数
# isolcpus=7 # 隔离 CPU 7（不参与调度）
# 或
# cpuhp/blacklist=7 # 黑名单 CPU 7
# 长期方案：
# 1. 联系硬件厂商更换 CPU（hard lockup 通常是 CPU 硬件故障）
# 2. 更新 BIOS/UEFI 固件（某些 lockup 是 BIOS bug）
# 3. 检查电源供应（电压不稳也可能导致 lockup）根因 C：内核 Bug 导致 Soft Lockup
bash
# 查看 lockup 时的调用栈：
dmesg -T | grep -A 30 'soft lockup.*stuck'
# 调用栈会显示卡在内核的哪个函数
# 常见 soft lockup 根因：
# 1. 内核死锁（两个锁互相等待）
# 2. 中断风暴（某个中断频率过高）
# 3. RCU stall（RCU 回调未及时处理）
# 4. 驱动 bug（网卡/存储驱动）
# 检查 RCU stall：
dmesg -T | grep -i 'rcu.*stall'
# 临时缓解：
# 增大 softlockup 阈值：
echo 60 > /proc/sys/kernel/watchdog_thresh
# 永久修复：
# 1. 升级内核（kernel bug 通常在后续版本修复）
# 2. 升级驱动（尤其是网卡、存储驱动）
# 3. 回滚最近的内核/驱动变更2.5 真实生产案例
案例：某金融客户 RKE2 集群（8 核 32G 物理机 worker 节点）
时间线：
14:00 - 运维收到告警：节点 szb12215 时间偏移 3 分 42 秒
14:02 - 监控数据出现 2 分钟断点
14:05 - 堡垒机 SSH 登录该节点超时（连续 3 次失败）
14:08 - 运维通过 IPMI 控制台登录（绕过 SSH）
排查过程：
1. dmesg -T | grep -iE 'lockup|tsc|clocksource'
→ 发现：
[14:01:23] tsc: Marking TSC unstable due to check_tsc_sync_source failed
[14:01:24] clocksource: Switched to clocksource hpet
[14:02:15] watchdog: BUG: soft lockup - CPU#3 stuck for 22s! [kworker/3:1]
[14:03:40] watchdog: Watchdog detected hard LOCKUP on cpu 7
2. cat /sys/devices/system/clocksource/clocksource0/current_clocksource
→ hpet（已从 tsc 切换）
3. chronyc tracking
→ System time: 222.4 seconds slow（偏移 3 分 42 秒）
→ RMS offset: 180+ seconds
4. cat /sys/devices/system/cpu/cpu7/online
→ 1（核心仍在线，但已无响应）
5. 手动隔离 CPU 7：
echo 0 > /sys/devices/system/cpu/cpu7/online
→ SSH 立即恢复可用
→ 监控数据恢复连续
→ 但时间仍偏移（需要手动修正）
6. chronyc makestep → 时间立即修正
根因分析：
- CPU 7 号核心发生硬件故障（Hard Lockup）
- 故障导致 TSC 同步检测失败
- 内核自动将时钟源从 TSC 切换到 HPET
- 切换瞬间时间跳变约 3 分钟
- HPET 精度低于 TSC，时间持续漂移
- sshd 进程和监控 Agent 偶尔被调度到 CPU 7 → 无法响应
长期修复：
1. 联系服务器厂商，更换 CPU（RMA）
2. 更新 BIOS 到最新版本
3. GRUB 添加 isolcpus=7（临时隔离）
4. 部署 clocksource 监控脚本（见下方）2.6 预防与监控体系
bash
#!/bin/bash
# /usr/local/bin/check-cpu-health.sh
# 部署到所有节点，通过 cron 每 5 分钟执行一次
# 1. 检查 lockup
LOCKUP_COUNT=$(dmesg -T --since "5 minutes ago" 2>/dev/null | grep -c 'lockup')
if [ "$LOCKUP_COUNT" -ge 1 ]; then
echo "CRITICAL: $LOCKUP_COUNT lockup events in last 5 minutes"
fi
# 2. 检查 clocksource 切换
CURRENT_CS=$(cat /sys/devices/system/clocksource/clocksource0/current_clocksource)
if [ "$CURRENT_CS" != "tsc" ]; then
echo "WARNING: clocksource is $CURRENT_CS (expected tsc)"
fi
# 3. 检查时间偏移
if command -v chronyc &>/dev/null; then
OFFSET=$(chronyc tracking 2>/dev/null | grep 'System time' | awk '{print $4}')
echo "INFO: current time offset = ${OFFSET}s"
fi
# 4. 检查 MCE
MCE_COUNT=$(dmesg -T --since "1 hour ago" 2>/dev/null | grep -ci 'machine check')
if [ "$MCE_COUNT" -gt 0 ]; then
echo "CRITICAL: $MCE_COUNT MCE events in last hour"
fi3. 两个场景的对比总结
| 维度 | 场景一：低 CPU + 高 Load | 场景二：低 CPU + 低 Load + 时间偏移 |
|---|---|---|
| 根因层级 | 用户态 / 文件系统 | 内核态 / 硬件 |
| 严重程度 | ⚠️ 中等 | 🔴 严重 |
| 影响范围 | 特定进程（D 状态） | 整个系统（部分核心不可用） |
| 排查入口 | ps aux + D 状态进程 | dmesg + clocksource |
| 关键命令 | cat /proc/PID/stack | dmesg | grep lockup |
| 紧急恢复 | umount -l / NFS 修复 | 隔离 CPU 核心 |
| 长期修复 | 换存储 / 修复 NFS | 换 CPU / 更新 BIOS / 升级内核 |
| 监控指标 | D 状态进程数 + iostat | clocksource + lockup 日志 |
| K8s 影响 | Pod 健康检查超时 | 节点 NotReady / SSH 不可用 |
4. 面试答题框架
面试官问："CPU 使用率低但 Load 高，你怎么排查？"
答题结构（3 分钟版本）：
1. 先澄清概念（30 秒）：
"首先我想说明，Linux 的 Load Average 不仅包含可运行进程，还包含 D 状态（不可中断睡眠）的进程。所以 CPU 使用率低但 Load 高，通常意味着有大量进程在等待 I/O 或内核锁。"
2. 给出排查路径（1.5 分钟）：
"我会按以下步骤排查：第一步，用
ps aux | awk '$8~/D/'统计 D 状态进程数量。第二步，查看这些进程的等待函数（WCHAN）和调用栈。第三步，用 iostat 检查磁盘 I/O 是否饱和。第四步，检查 NFS 挂载点是否卡死。第五步，查看 dmesg 中的 hung_task 警告。"
3. 给出解决方案（1 分钟）：
"根据根因不同，解决方案也不同：NFS 卡死用
umount -l紧急恢复并调整挂载参数；磁盘饱和升级存储并分离 I/O 密集型应用；内核锁竞争调整内核参数或升级内核。"
面试官问："CPU 和 Load 都正常，但时间偏移 3 分钟、监控断点、SSH 失败，你怎么看？"
1. 先定性（30 秒）：
"这组症状非常典型——所有看似无关的症状同时出现，说明它们有一个共同的根因。我的第一判断是 CPU 核心级别的故障，具体是 Hard Lockup 或 TSC 时钟源不稳定。"
2. 解释为什么（1 分钟）：
"CPU 使用率和 Load 正常，是因为只有个别核心卡住，其他核心正常工作，top 显示的是全局平均值。时间偏移是因为 TSC 不稳定后内核切换了时钟源。监控断点是因为监控 Agent 被调度到了卡住的核心。SSH 失败同理——sshd 进程被调度到不可用的核心。"
3. 给出排查和修复（1.5 分钟）：
"排查：第一步看 dmesg 中的 lockup 和 clocksource 日志。第二步确认当前时钟源是否从 tsc 切换到了 hpet。第三步确认是哪个 CPU 核心出了问题。紧急修复：将问题核心离线。长期修复：联系厂商更换硬件，更新 BIOS，并部署 clocksource 和 lockup 的监控脚本。"
面试官评价标准
| 水平 | 回答特征 |
|---|---|
| 初级（不通过） | "可能是网络问题"、"重启一下就好了"、"Load 高就是 CPU 忙" |
| 中级（基本通过） | 知道 D 状态进程导致 Load 高；知道 iostat 和 NFS；但对场景二没有思路 |
| 高级（通过） | 准确解释 Linux Load Average 定义；完整 D 状态排查路径；场景二能联想到 TSC/clocksource 切换 |
| 卓越（加分） | 主动提到 NMI watchdog、Hard Lockup；解释全局平均值的盲区；给出完整监控方案 |
5. 核心命令速查表
bash
# === 场景一：低 CPU + 高 Load ===
ps aux | awk '$8 ~ /D/' # D 状态进程列表
cat /proc/`<pid>`/stack # 进程内核调用栈
cat /proc/`<pid>`/wchan # 等待的内核函数
iostat -xz 1 # I/O 统计
iotop -oP # I/O 最大的进程
timeout 3 ls /mnt/nfs # 测试 NFS 挂载
dmesg -T | grep 'blocked for more than' # hung task 日志
umount -f -l /mnt/nfs # 强制 lazy umount
# === 场景二：时间偏移 + 监控断点 + SSH 失败 ===
dmesg -T | grep -iE 'lockup|tsc|clocksource|nmi|mce'
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
cat /sys/devices/system/cpu/cpu*/online
echo 0 > /sys/devices/system/cpu/cpu`N`/online # 隔离问题核心
chronyc tracking # 时间同步状态
chronyc makestep # 立即修正时间
mcelog --client # MCE 硬件错误
# === 通用 ===
perf top -g # 实时内核热点
sar -q 1 5 # Load 历史
mpstat -P ALL 1 # 每核 CPU 使用率
vmstat 1 # 系统全局状态