关注「Raymond运维」公众号，并设为「星标」，也可以扫描底部二维码加入群聊，第一时间获取最新内容，不再错过精彩内容。

Linux性能排查必备命令速查表：从CPU到网络的完整诊断指南

引言

在生产环境中，系统性能问题往往来得突然且影响巨大：应用响应变慢、用户投诉激增、服务器负载飙升。此时，运维工程师需要在最短时间内定位问题根源——究竟是CPU被打满、内存泄漏、磁盘I/O瓶颈，还是网络拥塞？

本文为您提供一份系统化的Linux性能排查速查表，覆盖CPU、内存、磁盘、网络、进程等核心维度，汇总20余个实战命令与工具。每个工具都包含使用场景、关键参数、输出解读与优化方向，让您能够快速建立诊断思路，从现象直达根因。

适用场景：应急故障处理、日常巡检、性能优化、容量规划、技术面试准备。

技术背景

Linux性能指标体系

Linux系统性能观测遵循USE方法论（Utilization、Saturation、Errors）和RED方法论（Rate、Errors、Duration）：

• • CPU维度：利用率、上下文切换、运行队列、CPU缓存命中率
• • 内存维度：物理内存使用率、Page Cache、Swap、内存回收压力、OOM事件
• • 磁盘I/O维度：IOPS、吞吐量、I/O队列深度、平均响应时间
• • 网络维度：带宽使用率、丢包率、重传率、连接状态分布
• • 进程维度：进程状态、文件描述符占用、系统调用追踪

核心内容

1. CPU性能排查

快速查看负载

# 查看系统负载（1/5/15分钟平均值）uptime# 输出：load average: 2.15, 1.98, 1.75# 实时监控（按1键切换CPU视图）top# 关键指标：%Cpu(s): us user | sy system | id idle | wa I/O wait | st steal

分核心CPU统计

# 安装sysstatsudo apt install sysstat -y  # Ubuntu/Debiansudo yum install sysstat -y  # RHEL/CentOS# 每2秒显示所有CPU核心mpstat -P ALL 2# 输出示例：CPU 0 %usr=78%, CPU 1 %usr=32.5%

性能事件采样

# 采样30秒CPU事件（需root）sudo perf record -F 99 -a -g -- sleep 30# 查看报告sudo perf report --stdio# 生成火焰图sudo perf script | \  FlameGraph/stackcollapse-perf.pl | \  FlameGraph/flamegraph.pl > flame.svg

关键告警阈值：

• • Load Average > 单核数：负载过高
• • %iowait > 20%：磁盘I/O瓶颈
• • %sy > 30%：可能存在内核模块问题

2. 内存管理排查

内存使用总览

# 显示内存统计（-h人类可读格式）free -h# 输出示例：# Mem:           15Gi       8.2Gi       1.5Gi       256Mi       5.8Gi       6.5Gi#              total       used       free     shared  buff/cache available# 重点关注 available（真实可用内存，Linux 3.14+）

进程内存细节

# 按内存使用排序进程ps aux --sort=-%mem | head -20# 查看特定进程内存映射（替换<PID>）sudocat /proc/<PID>/smaps_rollup# 关键字段：# Rss: 实际物理内存# Pss: 按比例分摊共享库的内存（更准确）# Private_Dirty: 进程独占且已修改的内存（检查泄漏）

内存压力监控

# 实时监控内存与Swap使用vmstat 3# 输出关键字段：# si/so: Swap In/Out（非零表示内存压力）# r: 运行队列（>2倍CPU核心数表示CPU饱和）

告警条件：

• • available < 10% 且 Swap used > 50%：需排查内存压力
• • si/so 持续 > 100 pages/s：需扩容内存
• • dmesg 出现"OOM Killer"：内存严重不足

3. 磁盘I/O性能

磁盘I/O统计

# 每2秒刷新扩展统计iostat -xz 2# 关键指标解读：# %util: 设备利用率（>80%表示饱和）# await: 平均I/O响应时间（HDD正常<10ms，SSD<1ms）# r/s + w/s: IOPS（每秒I/O操作数）# rrqm/s: 读请求合并率（越高越好）

进程级I/O监控

# 显示哪个进程在进行I/O（按I/O排序）sudo iotop -o# 输出：显示各进程的读写速度（KB/s）与I/O百分比

磁盘基准测试

# 安装fiosudo apt install fio -y# 顺序写测试（在/tmp/lab测试，避免破坏生产）sudomkdir -p /tmp/labsudo fio --name=seqwrite --rw=write --bs=128k --size=1G \  --numjobs=1 --runtime=60 --directory=/tmp/lab# 测试后清理sudorm -rf /tmp/lab

性能基线：

• • SSD随机读：>100k IOPS，延迟<1ms
• • HDD顺序读：>500 IOPS，延迟<10ms
• • %util持续>80%：需扩容或优化

4. 网络性能排查

网络连接状态

# 统计各状态TCP连接数ss -tan | awk '{print $1}' | sort | uniq -c# 输出示例：#   45 ESTAB（已建立连接）#   12 TIME-WAIT（等待关闭）#    3 LISTEN（监听状态）# 告警条件：TIME-WAIT > 1000或CLOSE-WAIT过多

网络流量监控

# 安装iftopsudo apt install iftop -y# 实时监控eth0网卡流量sudo iftop -i eth0# 显示每个连接的带宽占用（发送/接收速率）

抓包分析

# 抓取80端口流量（保存为pcap文件）sudo tcpdump -i eth0 port 80 -w /tmp/http.pcap -c 1000# 读取并查看tcpdump -r /tmp/http.pcap -nn | head -50# 高级过滤：抓取特定IP的SYN包sudo tcpdump -i eth0 'tcp[tcpflags] & tcp-syn != 0 and src host 192.168.1.100'

网卡硬件统计

# 查看网卡统计（丢包、错误、冲突）ethtool -S eth0 | grep -E 'drop|error|coll'# 查看协商速率ethtool eth0 | grep Speed# 应确保1000Mb/s或更高

5. 进程与系统调用分析

进程树与状态

# 显示进程层级关系pstree -p | grep <进程名># 查看僵尸进程ps aux | awk '$8 ~ /Z/ {print}'# 状态为Z的进程需终止其父进程或修复代码# 查看进程文件描述符占用ls -la /proc/<PID>/fd | wc -l

系统调用追踪

# 追踪运行中的进程系统调用（替换<PID>）sudo strace -p <PID> -T -tt -e trace=open,read,write,close -o /tmp/strace.log# 启动程序并追踪strace -T -tt curl https://example.com 2>&1 | head -100# 参数说明：# -T: 显示系统调用耗时# -tt: 打印微秒级时间戳# -e trace: 仅追踪指定系统调用

库函数调用追踪

# 追踪动态库函数调用sudo ltrace -p <PID> -o /tmp/ltrace.log# 适用于排查第三方库问题

6. 系统日志分析

内核日志

# 查看最近内核消息（含硬件错误、OOM事件）sudo dmesg -T | tail -200# 搜索OOM Killer事件sudo dmesg -T | grep -i 'killed process'# systemd系统使用journalctlsudo journalctl -k -p err -n 100

应用日志路径

• • Ubuntu/Debian：/var/log/syslog、/var/log/auth.log
• • RHEL/CentOS：/var/log/messages、/var/log/secure

# 实时监控系统日志sudotail -f /var/log/syslog# 搜索SSH登录失败sudo grep 'Failed password' /var/log/auth.log | tail -50

7. 内核参数优化

查看与配置

# 显示所有内核参数sysctl -a | less# 查看特定参数sysctl net.core.somaxconn# 临时修改（重启失效）sudo sysctl -w net.core.somaxconn=8192# 永久修改echo"net.core.somaxconn = 8192" | sudotee -a /etc/sysctl.confsudo sysctl -p

常用优化参数

# TCP连接队列大小（高并发推荐≥4096）net.core.somaxconn = 8192# 启用TIME-WAIT套接字复用net.ipv4.tcp_tw_reuse = 1# 文件描述符限制fs.file-max = 1048576# 虚拟内存脏页比例（减少I/O阻塞）vm.dirty_ratio = 10vm.dirty_background_ratio = 5

配置前务必备份

sudocp /etc/sysctl.conf /etc/sysctl.conf.bak

实践案例

案例1：CPU飙升100%定位

现象：服务器CPU使用率突然达到100%，订单处理超时。

排查流程

# 步骤1：定位进程top -c  # 找到java进程PID 1234，占用380%# 步骤2：线程级分析top -H -p 1234  # 发现线程ID 1250占用98%# 步骤3：获取线程堆栈printf'%x\n' 1250  # 转换为16进制0x4e2sudo jstack 1234 | grep -A 20 '0x4e2'# 输出显示：死循环在优惠券计算逻辑# 步骤4：性能采样验证sudo perf record -p 1234 -g -- sleep 10sudo perf report --stdio | head -50

优化方案：

• • 立即措施：重启应用，限流保护
• • 代码修复：优化算法，添加缓存
• • 容量规划：垂直扩容至8核，水平扩展3节点

结果：CPU平均使用率从95%降至45%，响应时间P99从4800ms降至220ms

案例2：内存泄漏检测

现象：服务运行3天后自动重启，日志显示OOM Killer触发。

排查步骤

# 确认OOM事件sudo dmesg -T | grep -i 'killed process'# 内存使用追踪（每5秒记录）whiletrue; do  ps -p 5678 -o pid,vsz,rss,%mem,cmd >> /tmp/mem_monitor.logsleep 5done# 分析趋势（RSS从2GB增长到14GB）awk '{print $3}' /tmp/mem_monitor.log | head -100# 详细内存映射sudocat /proc/5678/smaps_rollup# Private_Dirty: 13582340 kB（13GB，异常）# 使用valgrind检测泄漏valgrind --leak-check=full ./video_service

修复：在缓冲区使用完后调用av_free()释放，设置systemd内存限制结果：连续运行30天，内存稳定在3.5GB，OOM事件清零

案例3：磁盘I/O瓶颈分析

现象：数据库查询响应从50ms升至2秒，慢查询激增。

排查流程

# I/O统计iostat -xz 2# %util: 99.8，await: 152.3ms（异常）# 定位I/O进程sudo iotop -o# TID 3456 mysqld占用45.2 M/s读速度# 分析慢查询sudocat /var/log/mysql/mysql-slow.log | tail -100# 发现大量全表扫描，缺少索引# 块设备追踪（10秒采样）sudo blktrace -d /dev/sda -o - | blkparse -i - | head -200

优化方案：

• • 添加数据库索引（ALTER TABLE ADD INDEX）
• • 迁移数据目录至SSD
• • 调整I/O调度器（echo mq-deadline > /sys/block/sda/queue/scheduler）

结果：磁盘%util从99.8%降至35%，查询响应时间P95从1800ms降至55ms

最佳实践清单

1. 1. 建立性能基线：业务低峰采集CPU/内存/I/O基准数据
2. 2. 分层排查原则：先宏观（Load/top）后微观（perf/strace）
3. 3. 保留故障现场：优先采集数据再重启
4. 4. 工具版本管理：生产统一安装sysstat/perf/iotop（≥12.x）
5. 5. 自动化巡检：使用cron定时采集sar数据，保留30天历史
6. 6. 避免破坏操作：测试在/tmp/lab，勿直接操作生产挂载点
7. 7. 日志轮转配置：防止/var/log填满磁盘（logrotate配置）
8. 8. 网络抓包规范：限制包数量或时长，敏感环境需审批
9. 9. 内核参数变更流程：备份→验证→写入→监控24小时
10. 10. 多维交叉验证：结合perf/sar确认top结果
11. 11. 容量规划前瞻：资源>70%启动扩容评估
12. 12. 监控告警分级：P0立即处理，P1/P2分级响应
13. 13. 文档化排查路径：建立常见问题的Runbook
14. 14. 权限最小化：仅授予必要的sudo权限
15. 15. 定期演练：每季度性能故障演练

总结与展望

本文系统化梳理了Linux性能排查的核心工具与方法论，通过3个完整实战案例帮助运维工程师快速定位问题。

核心要点：

1. 1. 遵循USE/RED方法论分层排查
2. 2. 关注关键指标阈值
3. 3. 结合业务场景优化
4. 4. 保持工具链现代化

技术演进趋势：

• • eBPF普及：bpftrace替代传统工具，无需修改内核
• • 可观测性标准化：OpenTelemetry集成指标/日志/追踪
• • AI辅助诊断：基于历史数据的异常检测
• • 容器化监控：cAdvisor适配Kubernetes环境

FAQ

Q1：Load Average多高才算异常？

正常：单核<1.0，多核<核心数（4核系统Load<4.0）。但需结合%wa判断：若%wa高则为I/O瓶颈而非CPU瓶颈。

Q2：内存占用90%是否需扩容？

不一定。关键看available字段（>10%为健康）与Swap使用情况。若持续增长且si/so非零需扩容。

Q3：如何选择I/O调度器？

• • SSD/NVMe：none或mq-deadline
• • 机械硬盘：mq-deadline或bfq
• • 数据库：mq-deadline（平衡吞吐与延迟）

Q4：perf采样会影响生产性能吗？

轻微影响，可控。推荐频率≤99Hz（开销<1% CPU），采样30-60秒。

Q5：TIME-WAIT连接过多如何优化？

启用端口复用：sudo sysctl -w net.ipv4.tcp_tw_reuse=1

Q6：如何衡量故障处理有效性？

MTTD（检测时间<2分钟）、MTTR（恢复时间<15分钟）、故障影响面（<5%）、重复故障率（=0）。