查系统状态优先看 dmesg 和 journalctl -b：dmesg 获取内核级异常（硬件报错、驱动崩溃、OOM），需及时 dmesg -T 保存；journalctl -b 查用户空间服务日志，应配合 -b -1、-p err、-u、--since 等参数精准过滤。
查系统状态优先看 dmesg 和 journalctl -b
内核级异常（如硬件报错、驱动崩溃、OOM killer 触发）通常不会出现在普通日志里，dmesg 是第一手来源。但要注意，默认输出会滚动刷屏，且重启后缓冲区清空——所以故障刚发生时立刻执行 dmesg -T（带时间戳）并重定向保存，比如 dmesg -T > /tmp/dmesg.log。
journalctl -b 则覆盖用户空间服务启动和运行期日志，比 /var/log/messages 更全、更结构化。若系统启用了 systemd，它应是默认首选。常见误操作是只查 -b（本次启动），却忽略 -b -1（上一次启动），而很多“重启后变好”的问题，真正线索藏在前一次崩溃的 journal 里。
- 加
-p err只看错误级别：journalctl -b -p err - 按服务过滤：
journalctl -u sshd -n 50查最近 50 行 sshd 日志 - 时间范围用
--since "2024-06-10 14:00"，避免依赖系统时区混乱
磁盘 I/O 卡顿时别只盯 top，用 iostat -x 1 看真实瓶颈
top 显示的 %wa（I/O wait）只是 CPU 等待 I/O 的比例，它无法区分是磁盘慢、路径拥塞，还是应用本身频繁小写。真正定位得靠 iostat -x 1（需 sysstat 包）。
关键字段不是 %util（常被误读为“磁盘忙”，实际是队列非空时间占比），而是 await（单次 I/O 平均耗时）和 svctm（设备服务时间）。当 await >> svctm，说明 I/O 请求在队列里积压了，可能是磁盘过载、RAID 卡缓存失效，或虚拟机底层存储争抢。
-
avgqu-sz持续大于 1 表示请求排队，结合await升高可确认瓶颈在存储层 - SSD 场景下
await超过 10ms 就值得警惕；HDD 超过 50ms 通常已异常 - 注意
iostat默认不显示设备名全称（如nvme0n1p1），加-d参数才显示
strace 抓进程卡死时，慎用 -f 和 -e trace=network
当某个进程无响应但 CPU 占用低，strace -p 能看到它最后阻塞在哪个系统调用上——比如停在 recvfrom 就是等网络数据，卡在 futex 很可能是锁竞争。
但盲目加 -f（跟踪子进程）会导致输出爆炸，尤其 Java/Python 进程 fork 频繁，日志瞬间刷屏，反而掩盖关键调用。更稳妥的是先不加 -f，确认主进程行为；真需子进程信息，再用 strace -ff -o /tmp/strace.out -p 分文件记录。
- 只关心网络行为？用
-e trace=network过滤，避免混入大量read/write - 避免用
-s 0（不限制字符串长度）——某些返回值超长会拖慢strace本身，甚至卡住目标进程 - 生产环境慎用
strace长时间挂载，它会让目标进程单线程执行，可能加剧业务延迟
内存泄漏排查不能只看 free，要结合 cat /proc/meminfo 和 smem
free -h 显示的 available 值容易误导：它包含可回收的 page cache，不代表真正空闲内存。真实压力要看 MemAvailable 是否持续低于 MemTotal * 0.1，以及 SwapCached 是否增长（说明内核正把匿名页换出又换回）。
smem（需单独安装）能按进程维度统计 RSS、PSS、USS，比 ps aux --sort=-%mem 更准——后者只看 RSS，会重复计算共享库内存。一个 Java 进程 RSS 2GB，PSS 可能只有 800MB，因为大量 JNI 库被多个 JVM 共享。
- 查谁占了 page cache：
smem -s pss -r | head -20，PSS 高但 USS 低，大概率是缓存大户 - 关注
Inactive(file)和Active(file)在/proc/meminfo中的比例，若Active(file)远高于Inactive(file)，说明文件缓存长期没被回收，可能影响新分配 - 容器环境务必看
cgroup内存限制：cat /sys/fs/cgroup/memory/memory.limit_in_bytes和memory.usage_in_bytes
最易被忽略的一点：很多“内存不足”报警其实源于 vm.swappiness=1 下的极端保守策略——内核宁可 OOM kill 进程，也不愿换出匿名页。这时 /proc/meminfo 里的 SwapTotal 是 0 或极小，但 DirectMap 区域却持续增长，得回头检查内核启动参数和 cgroup 配置。
