引言
在生产环境中，系统性能问题往往来得突然且影响巨大：应用响应变慢、用户投诉激增、服务器负载飙升。此时，运维工程师需要在最短时间内定位问题根源——究竟是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统计
# 安装sysstat
sudo apt install sysstat -y # Ubuntu/Debian
sudo 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百分比
磁盘基准测试
# 安装fio
sudo apt install fio -y
# 顺序写测试（在/tmp/lab测试，避免破坏生产）
sudomkdir -p /tmp/lab
sudo 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过多
网络流量监控
# 安装iftop
sudo 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系统使用journalctl
sudo 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.conf
sudo 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 = 10
vm.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进制0x4e2
sudo jstack 1234 | grep -A 20 '0x4e2'
# 输出显示：死循环在优惠券计算逻辑
# 步骤4：性能采样验证
sudo perf record -p 1234 -g -- sleep 10
sudo 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.log
sleep 5
done
# 分析趋势（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. 建立性能基线：业务低峰采集CPU/内存/I/O基准数据
- 2. 分层排查原则：先宏观（Load/top）后微观（perf/strace）
- 3. 保留故障现场：优先采集数据再重启
- 4. 工具版本管理：生产统一安装sysstat/perf/iotop（≥12.x）
- 5. 自动化巡检：使用cron定时采集sar数据，保留30天历史
- 6. 避免破坏操作：测试在/tmp/lab，勿直接操作生产挂载点
- 7. 日志轮转配置：防止/var/log填满磁盘（logrotate配置）
- 8. 网络抓包规范：限制包数量或时长，敏感环境需审批
- 9. 内核参数变更流程：备份→验证→写入→监控24小时
- 10. 多维交叉验证：结合perf/sar确认top结果
- 11. 容量规划前瞻：资源>70%启动扩容评估
- 12. 监控告警分级：P0立即处理，P1/P2分级响应
- 13. 文档化排查路径：建立常见问题的Runbook
- 14. 权限最小化：仅授予必要的sudo权限
- 15. 定期演练：每季度性能故障演练
总结与展望
本文系统化梳理了Linux性能排查的核心工具与方法论，通过3个完整实战案例帮助运维工程师快速定位问题。
核心要点：
- 1. 遵循USE/RED方法论分层排查
- 2. 关注关键指标阈值
- 3. 结合业务场景优化
- 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）
文末福利
网络监控是保障网络系统和数据安全的重要手段，能够帮助运维人员及时发现并应对各种问题，及时发现并解决，从而确保网络的顺畅运行。
谢谢一路支持，给大家分享6款开源免费的网络监控工具，并准备了对应的资料文档，建议运维工程师收藏（文末一键领取）。
备注：【监控合集】
100%免费领取
一、zabbix
二、Prometheus
内容较多，6款常用网络监控工具（zabbix、Prometheus、Cacti、Grafana、OpenNMS、Nagios）不再一一介绍， 需要的朋友扫码备注【监控合集】，即可100%免费领取。
以上所有资料获取请扫码
备注：【监控合集】
100%免费领取
（后台不再回复，扫码一键领取）
本文链接：https://www.yunweipai.com/47461.html
网友评论comments