Linux实用运维与系统性能排查技巧指南

在日常的Linux服务器运维与开发工作中，系统性能瓶颈、资源占用过高或服务响应迟钝是运维工程师和开发者经常遇到的挑战。本文将围绕CPU、内存、磁盘I/O以及网络四大核心维度，详细梳理一套高效且实用的Linux性能排查与优化技巧。

一、 CPU 性能排查与分析

当系统响应变慢或负载高企时，CPU往往是首要排查对象。

1. 查看系统整体负载 (uptime / top)

使用 uptime 命令可以快速查看系统的1分钟、5分钟和15分钟平均负载（Load Average）：

uptime

如果平均负载持续高于CPU核心总数，说明系统存在CPU资源争抢或I/O等待。

在 top 或 htop 中，重点关注以下指标：

• %us (user): 用户态CPU使用率。若高，说明应用程序计算密集。
• %sy (system): 内核态CPU使用率。若高，可能是系统调用过于频繁或内核锁竞争。
• %wa (iowait): CPU等待磁盘I/O响应的时间占比。若高，说明瓶颈在磁盘存储。

2. 定位高CPU消耗的具体线程

使用 pidstat 可以按进程或线程粒度监控CPU使用情况：

pidstat -u 1 5

若需定位某进程内部的高CPU线程，可配合 top -Hp <PID> 找到线程ID（TID），再通过 gstack 或 jstack 打印堆栈。

二、 内存瓶颈诊断与内存泄漏排查

内存不足不仅会导致系统频繁进行 Swap 交换，严重时还会触发内核 OOM Killer 杀掉关键进程。

1. 内存使用概览 (free -m)

free -h

关键指标说明：

• total: 物理内存总量。
• used: 已分配内存。
• free: 完全未使用的物理内存。
• buff/cache: 用于页缓存（Page Cache）和缓冲区（Buffers）的内存。Linux会优先利用闲置内存做缓存，需要时会自动释放。

2. 检查 Swap 交换与 OOM 风险

使用 vmstat 监控 Swap 进出情况：

vmstat 1 5

关注 si (swap in) 和 so (swap out)。若 si/so 持续大于0，说明物理内存紧张，系统正在频繁读写 Swap 分区，性能会剧烈下降。

通过 dmesg 查看是否有 OOM 日志：

dmesg -T | grep -i oom

三、 磁盘 I/O 性能诊断

磁盘读写吞吐（Throughput）与每秒I/O操作数（IOPS）是影响数据库及日志密集型应用的关键。

1. 使用 iostat 排查磁盘瓶颈

iostat -xz 1 5

核心字段解析：

• r/s, w/s: 每秒读写次数。
• rkB/s, wkB/s: 每秒读写数据量（KB）。
• await: 读写请求的平均等待时间（毫秒）。一般应小于 10ms，若达到几十甚至上百毫秒，说明磁盘I/O严重过载。
• %util: 磁盘Busy百分比。若接近 100%，表明磁盘性能已达上限。

2. 使用 iotop 查找高I/O进程

类似于 top，iotop 可以按读写速度对进程排序：

iotop -oP

四、 网络状态排查与连接数分析

网络延迟、丢包或连接数暴涨是常见网络故障。

1. 查看网络套接字状态 (ss / netstat)

相比传统的 netstat，ss 命令执行速度更快：

ss -s
ss -antp | grep ESTAB | wc -l

分析 TCP 连接状态分布（如 TIME_WAIT、CLOSE_WAIT 数量），若 CLOSE_WAIT 过多，通常代表应用程序未正常关闭连接。

2. 网络抓包与路由诊断

• ping / mtr: 测试网络连通性与沿途路由丢包率。
• tcpdump: 用于精准抓包分析 HTTP/TCP 协议交互：

tcpdump -i eth0 tcp port 80 -nn -X

五、 总结与最佳实践

定位 Linux 性能问题的基本原则是“从宏观到微观”：

1. 先宏观：通过 top、vmstat、free、iostat 等工具判断瓶颈位于 CPU、内存、磁盘还是网络；
2. 后微观：使用 pidstat、iotop、ss 或日志分析工具定位到具体的进程、线程甚至代码行；
3. 建立监控：结合 Prometheus + Grafana 等监控平台，设置合理的告警阈值，做到问题早发现早处置。

希望本文提供的运维与诊断排查技巧能够帮助大家在日常服务器运维中快速定位问题，保障业务系统的稳定运行！