日常排查选htop，最小化环境或脚本集成选top；htop支持鼠标滚动、颜色高亮、树状视图和f3/f4过滤，按cpu%排序后可快速定位异常进程，top需手动按p键且默认不显示完整命令行。
top 和 htop 哪个更适合快速定位高 CPU 进程
直接看结论：日常排查选 htop，最小化环境或脚本集成选 top。
htop 支持鼠标滚动、颜色高亮、树状进程视图和 F3/F4 过滤，按 CPU% 列排序后一眼就能揪出异常进程；top 虽轻量（默认几乎全发行版自带），但默认不显示完整命令行、不支持横向滚动查看长进程名，且排序需手动按 P 键——容易漏掉被截断的 Java 或 Node.js 进程。
-
top -c才能显示完整命令行，否则只显示二进制名（如java而非java -Xmx2g -jar app.jar） -
htop需要额外安装（yum install htop或apt install htop），AlmaLinux/RHEL 8+ 还得先启用 EPEL - 自动化脚本中慎用
htop：它本质是交互式 TUI 工具，非管道友好；想取数据请用ps -eo pid,ppid,cmd,%cpu --sort=-%cpu | head -20
iostat -x 1 看到的 %util 接近 100% 就代表磁盘瓶颈吗
不一定。%util 达到 100% 只说明设备在采样周期内“有 I/O 请求的时间占比”饱和，并不等于吞吐打满或延迟爆炸。
关键要看配套指标：await（平均每次 I/O 等待时间）和 r/s+w/s（每秒读写次数）。比如一块 NVMe 盘 %util=100% 时 await=0.2ms 完全正常；而一块老旧 SATA 盘若 %util=95% 且 await>100ms，才是真瓶颈。
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
-
iostat -dx 1每秒刷新一次详细指标，重点关注await、svctm（已废弃，忽略）、%util三列 -
%util高但rkB/s和wkB/s很低 → 可能是小 IO 频繁（如日志刷盘），不是吞吐问题而是 IO 模式问题 - RAID 卡或 NVMe 多队列设备下，
%util失效（单队列统计偏差），此时应看iostat -x的aqu-sz（平均队列深度）和avgqu-sz
free -h 显示 available 内存很低，但系统没 OOM，怎么回事
这很常见，available 是内核估算的“可立即分配内存”，包含空闲内存 + 可快速回收的缓存（PageCache 和 Slab 中部分），不代表真的快耗尽了。
真正危险信号是：si/so（swap 换入/换出）持续非零，或 vmstat 1 中 cs（上下文切换）飙升同时 in（中断）也高——说明内存压力已传导到调度和 I/O 层。
-
free -h的available值低于总内存 10% 才需警惕，低于 5% 且swapon --show显示 swap 使用 >20%，才真该扩容或调优 -
slabtop查看内核 slab 缓存是否异常增长（如dentry或inode占用突增），可能是文件句柄泄漏 -
smem -u -k按用户统计实际物理内存占用，比ps aux --sort=-%mem更准（排除共享内存干扰）
vmstat 1 输出里 cs 和 in 同时飙高，怎么快速缩小范围
先确认是不是软中断（si）主导：运行 cat /proc/interrupts | grep -E "(soft|NET)"，如果 NET_RX 或 HI_SOFTIRQ 行数字远超其他项，基本锁定网络软中断过载。
再分方向排查：若 in（硬件中断）也高，查 /proc/interrupts 看具体设备（如网卡、NVMe）中断号是否集中在单个 CPU 核；若 cs 单独高，大概率是线程数过多或锁竞争激烈。
-
mpstat -P ALL 1看各核%soft占比，确认是否某核被软中断霸占 -
perf top -e irq:softirq_entry可追踪软中断触发函数（需 root），常见于 netfilter 规则过多或 conntrack 表满 -
cat /proc/sys/net/netfilter/nf_conntrack_count对比nf_conntrack_max，超限会引发大量丢包和重传，推高软中断
vmstat 1、iostat -dx 1、pidstat -u 1 三个命令窗口并排跑 30 秒，交叉比对时间戳对齐的峰值。
