生产环境Linux性能巡检需定期验证关键指标是否在健康基线内，重点查资源饱和度、异常行为、配置漂移和日志线索；CPU看负载、us/sy占比及核均衡性；内存重在Available和SwapUsed；I/O关注await与队列长度；网络查重传、丢包及缓冲区；内核和服务须核对sysctl参数与服务状态。
生产环境 Linux 性能巡检不是“出了问题再查”，而是定期验证关键指标是否在健康基线内，提前识别隐患。重点看资源饱和度、异常行为、配置漂移和日志线索，而非堆砌命令。
CPU 使用率与负载：看是否真忙，还是假堵
仅看 top 或 htop 的 CPU% 容易误判。需结合以下三点判断：
-
负载（Load Average）是否持续高于 CPU 逻辑核数：如 4 核机器，15 分钟 load > 4 持续 5 分钟以上，说明有任务排队；用
uptime或cat /proc/loadavg查 - us（用户态）和 sy（内核态）占比是否异常：sy 长期 > 30%，可能有频繁系统调用或锁争用；us 高但进程响应慢，需查是否被 iowait 或 steal 拉高
-
是否存在单核打满、其余空闲的不均衡现象：用
mpstat -P ALL 1 3观察各核利用率，排查绑核、中断集中或 NUMA 不平衡问题
内存与交换：警惕“够用”背后的隐性压力
不只看 free -h 的可用内存，更要看内核如何管理内存压力：
-
检查
Available列是否持续低于总内存 15%：该值含可快速回收的缓存，比Free更反映真实余量 -
确认
SwapUsed是否非零且增长：即使未 OOM，swap-in/out 频繁会严重拖慢响应；用vmstat 1 5看si/so列是否 > 0 -
查看
/proc/meminfo中PageTables和Slab是否异常膨胀：可能预示内存泄漏（如内核模块、大量小对象分配）
I/O 延迟与队列：磁盘不是瓶颈，延迟才是
吞吐量高不等于 I/O 健康，毫秒级延迟积压会传导至应用层：
-
用
iostat -x 1 3关注%util（谨慎解读）、await（平均 I/O 延迟）和svctm（实际服务时间）：await > 20ms（机械盘）或 > 2ms（SSD）且持续存在，需深挖 -
检查
avgqu-sz（平均队列长度）是否长期 > 1：说明 I/O 请求持续堆积，结合iotop定位高 IOPS 进程 -
确认
/sys/block/*/queue/scheduler是否匹配设备类型：NVMe 应用none，SATA SSD 推荐mq-deadline，避免默认cfq引入额外延迟
网络与连接：丢包、重传、队列一个都不能少
网络问题常表现为“间歇性超时”，需从协议栈多层验证：
-
用
ss -s查总连接数及memory字段：若mem显著增长，可能 socket 缓冲区积压，结合netstat -s | grep -i "retrans|reset"看重传/异常关闭次数 -
检查
/proc/net/snmp中 TCP 的RetransSegs和EstabResets：小时级增长 > 0.1% 总发包量即属异常 -
确认网卡 RX/TX 队列无丢包：用
ethtool -S eth0 | grep -i "drop\|error\|over"，重点关注rx_missed_errors（Ring Buffer 溢出）和tx_aborted_errors
内核与服务状态：配置没改，不代表它还生效
生产环境最易被忽略的是“静态配置漂移”和“服务隐性降级”：
-
核对关键 sysctl 参数是否仍为预期值：如
net.ipv4.tcp_tw_reuse、vm.swappiness、fs.file-max，用sysctl -n 参数名直接取值比sysctl -a更可靠 -
检查 systemd 服务是否 active（running）且无 recent fail：用
systemctl list-units --state=failed和systemctl status xxx | grep -E "(Active:|since|Failed)" -
扫描
/var/log/messages或journalctl --since "2 hours ago"中的WARN、ERROR、OOMKilled、hardware error关键词：不求全读，但必须覆盖最近 2 小时
巡检不是一次执行十几个命令，而是带着问题意识，用最少命令验证最关键的假设。每次记录基线值，比绝对数值更有意义。不复杂但容易忽略。
