Linux 性能问题不能只看一个 CPU 使用率或 Load Average。生产排查需要先确认业务影响，保存现场，再按照 CPU、内存、磁盘 I/O、网络和应用依赖逐层缩小范围。系统维护还必须覆盖内核升级、备份、恢复演练和回滚。
排查原则：先测量再修改；先找瓶颈资源，再找制造瓶颈的进程；不要在缺少证据时通过重启“解决”问题。
一、适用环境与准备
示例适用于常见 systemd Linux 发行版。部分工具来自 sysstat、iotop、perf、smartmontools 和 ethtool 软件包。
cat /etc/os-release
uname -r
lscpu
free -h
lsblk -f
ip -br addr
uptime生产排查前记录故障时间、影响接口、错误率、延迟、变更记录和告警曲线。命令输出可能含主机名、IP、路径和业务数据，对外分享前要脱敏。
二、建立性能基线
没有正常时期的基线，就难以判断当前数据是否异常。建议至少持续采集：
CPU 使用率、运行队列、上下文切换和软中断。
内存可用量、工作集、Swap、缺页和 OOM。
磁盘延迟、队列、吞吐、利用率和文件系统容量。
网络吞吐、丢包、重传、连接数和 conntrack。
进程级 CPU、内存、I/O、线程数和文件描述符。
应用请求量、错误率、延迟、饱和度及依赖指标。
基线应区分工作日、批处理窗口、发布时段和业务高峰，并保留容量增长趋势。
三、先使用 USE 方法定位资源
USE 表示 Utilization、Saturation 和 Errors：利用率、饱和度和错误。对每类资源都回答这三个问题。
uptime
vmstat 1 10
mpstat -P ALL 1 5
sar -q 1 5
free -h
sar -r 1 5
iostat -xz 1 5
sar -n DEV,TCP,ETCP 1 5先通过系统级指标判断瓶颈在哪一层，再进入进程和应用。不要一开始就在数千个进程中盲目搜索。
四、CPU 排查
mpstat -P ALL 1 10
pidstat -u -t 1 10
ps -eo pid,ppid,user,stat,psr,%cpu,%mem,etime,cmd --sort=-%cpu | head -n 30
top -H -p PID
perf top -p PID重点区分：
user 高：应用计算、序列化、压缩、加密或死循环。
system 高：系统调用、内核路径、网络和存储操作频繁。
iowait 高：CPU 在等待 I/O，但还要结合磁盘延迟和队列判断。
steal 高：虚拟机被宿主机抢占 CPU。
soft 高：软中断压力，常见于网络包量、驱动或中断分布问题。
单进程 400% CPU 在多核机器上可能只是使用 4 个逻辑核。判断前必须同时查看核数、单核分布、运行队列和业务容量。
五、Load Average 的正确理解
uptime
cat /proc/loadavg
vmstat 1 10
ps -eo state,pid,ppid,wchan:32,cmd | awk '$1 ~ /D|R/'Linux 负载包含正在运行和不可中断睡眠任务。负载高可能来自 CPU 饱和，也可能来自磁盘、NFS、块设备或内核锁等待。将 Load Average 与 CPU 核数、vmstat 的 r/b 和 I/O 指标结合分析。
六、内存、Swap 与 OOM
free -h
cat /proc/meminfo
vmstat 1 10
pidstat -r 1 10
ps -eo pid,user,rss,vsz,%mem,etime,cmd --sort=-rss | head -n 30
journalctl -k --since '-2 hours' | grep -Ei 'oom|out of memory|killed process'
systemctl show app.service -p MemoryCurrent -p MemoryMaxLinux 会利用空闲内存做页缓存，所以 free 较小并不等于内存不足，应关注 available、持续 Swap 活动、重大缺页、内存回收和 OOM 记录。
出现 OOM 时先区分宿主机 OOM、systemd cgroup 限制、容器 OOM 和应用主动退出。保存 journalctl -k、进程 RSS、cgroup 限制和应用堆信息后再重启。
七、磁盘 I/O 与文件系统
iostat -xz 1 10
pidstat -d 1 10
iotop -oPa
lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS
findmnt
df -hT
df -i
lsof +L1
journalctl -k -p warning --since '-2 hours'常见指标：
await：I/O 完成的平均等待时间。aqu-sz：平均队列长度。%util：设备繁忙程度；在并行设备和虚拟存储上不能单独作为结论。r/s、w/s、rkB/s、wkB/s：IOPS 和吞吐。
排查顺序是：确定受影响挂载点和块设备，确认读写类型，找到 I/O 进程，再检查设备、阵列、云盘、NFS 和应用访问模式。不要在高 I/O 现场直接执行无范围限制的 du 或 find。
八、网络性能
ip -s link
ss -s
ss -tan state established | wc -l
sar -n DEV,TCP,ETCP 1 10
nstat -az | grep -Ei 'Retrans|Listen|Drop|Error'
ethtool -S eth0 2>/dev/null | grep -Ei 'drop|error|miss|timeout'
tracepath target.example
mtr -rwzc 20 target.example关注网卡错误、丢包、TCP 重传、监听队列溢出、连接跟踪容量、MTU 和跨区域延迟。吞吐低不一定是带宽不足，也可能是单连接窗口、磁盘、CPU、TLS 或应用并发限制。
九、文件描述符、进程和线程
ulimit -n
cat /proc/sys/fs/file-nr
ls /proc/PID/fd | wc -l
cat /proc/PID/limits
ps -eLf | awk '$4 == PID' | wc -l
systemctl show app.service -p LimitNOFILE -p TasksMax文件描述符泄漏会表现为新连接或新文件打开失败。提高限制只能暂时止损，仍要找到泄漏对象，并同时核对应用、systemd Unit、系统全局和容器限制。
十、现场采集与止损
建议在受控目录保存最小现场包：
case_dir=/var/tmp/perf-case-$(date +%F-%H%M%S)
mkdir -m 0700 "$case_dir"
uptime > "$case_dir/uptime.txt"
vmstat 1 10 > "$case_dir/vmstat.txt"
mpstat -P ALL 1 5 > "$case_dir/mpstat.txt"
iostat -xz 1 5 > "$case_dir/iostat.txt"
ps auxwwf > "$case_dir/ps.txt"
ss -s > "$case_dir/ss-summary.txt"
journalctl -k --since '-1 hour' > "$case_dir/kernel.log"止损应选择影响最小且可回滚的手段：限流、摘除单节点、暂停异常批任务、扩容、降低并发或回滚版本。终止进程和重启主机放在证据保存之后，并提前确认数据一致性风险。
十一、内核升级流程
阅读发行版公告和 CVE，确认硬件、驱动、容器和安全软件兼容性。
验证启动分区空间、当前内核和可回退内核。
在测试环境执行功能、性能和重启验证。
备份关键配置，确认控制台或带外管理可用。
先升级一台非关键节点，排空流量后重启。
验证内核、网卡、存储、时间同步、容器和业务。
观察稳定后分批推进；异常时从旧内核启动并回滚软件包。
uname -r
df -h /boot
rpm -q kernel 2>/dev/null || dpkg -l 'linux-image*'
grubby --default-kernel 2>/dev/null || true
journalctl -b -p warning --no-pager
systemd-analyze blame | head不要将全量节点安排在同一维护窗口重启。高可用集群应逐节点排空、升级、验证和恢复流量。
十二、备份设计
备份前先明确 RPO、RTO、保留周期、加密、异地副本和恢复责任人。配置文件、应用数据、数据库和系统镜像的备份方式不同。
配置：版本控制加受控备份，排除 Secret 或单独加密。
数据库：使用数据库一致性备份、快照和日志链，不直接复制运行中的数据目录。
文件：使用 rsync、快照或备份软件，并保存 ACL、扩展属性和校验值。
系统：记录软件包、Unit、挂载、网络、内核参数和自动化代码，避免只依赖整机镜像。
rsync -aHAX --numeric-ids --delete-delay /srv/data/ backup:/backup/host/data/
sha256sum backup-file.tar.zst > backup-file.tar.zst.sha256
getfacl -R /srv/app > app-acl.txt
findmnt --json > findmnt.json--delete 类选项会同步删除目标文件，必须确认源目标方向、保留快照并先使用 dry-run。
十三、恢复演练
选择隔离环境和明确的恢复点。
校验备份文件完整性、解密密钥和依赖版本。
按顺序恢复系统配置、应用、数据和权限。
验证文件数量、校验值、数据库一致性和业务功能。
记录实际 RPO、RTO、缺失步骤和人工依赖。
将演练问题更新到自动化脚本和运行手册。
没有定期恢复验证的备份不能视为可靠备份。至少按季度抽样恢复关键系统，并对重大架构变化追加演练。
十四、维护后的验证
systemctl --failed
journalctl -b -p warning --no-pager
ss -lntup
df -hT
df -i
free -h
uptime
curl -fsS https://service.example.com/health除了技术指标，还要验证登录、查询、写入、异步任务和下游调用等核心业务路径，并观察错误率、P95/P99 延迟和资源曲线。
十五、交付检查清单
正常基线、故障时间和影响范围已经记录。
CPU、内存、I/O、网络和进程均有证据支撑。
止损动作可回滚，并未破坏现场或数据。
内核升级保留旧内核和带外恢复路径。
备份覆盖配置、数据、权限和依赖信息。
备份已通过隔离恢复演练，而不只是显示成功。
维护后系统、监控、告警和业务验证均已完成。
总结
性能排查的核心是从业务影响出发，通过系统级指标定位瓶颈资源，再追踪到进程和代码。系统维护的核心是小批量、可验证、可回退；备份的核心是恢复成功。把性能基线、变更流程和恢复演练结合起来，才能形成真正可靠的 Linux 运维体系。