Linux 服务器性能优化实战：15 个高频命令帮你定位瓶颈、分析系统故障
在服务器运维中，Linux 性能问题往往藏在 “CPU 飙升”“内存爆满”“磁盘 IO 卡顿” 的表象下。多数时候，我们无需复杂工具，用好系统自带的命令就能精准定位瓶颈、完成调优。本文从CPU、内存、磁盘、网络四大核心维度，梳理 15 个必学命令，附实战场景和调优思路，帮你从 “只会查日志” 进阶到 “主动优化性能”。
一、CPU 性能：定位 “吃资源” 的进程，避免算力浪费
CPU 是服务器的 “大脑”，一旦出现高负载，整个服务响应都会变慢。核心是找到 “占用 CPU 过高的进程 / 线程”，判断是正常业务还是异常消耗!
1. top：实时监控 CPU 与进程状态（最常用）
- 作用：动态显示进程 CPU、内存占用，默认每 3 秒刷新一次，是排查 CPU 问题的 “第一工具”。
- 关键指标解读：
%Cpu(s)行：us（用户进程占用 CPU 百分比，正常应≤70%，过高说明业务进程消耗大）、sy（内核进程占用，正常≤30%，过高可能是系统调用频繁）、id（空闲 CPU，过低则负载高）；- 进程列表：
%CPU列排序（按P键），可快速找到 “CPU 杀手”（如异常的java进程、nginxworker 进程）。
- 实战场景：发现
us持续 90%+，排序后看到某python脚本占 80% CPU，检查后发现是循环逻辑漏洞，修复后 CPU 负载降至正常。
2. mpstat：细分 CPU 核心负载，排查 “单核过载”
- 作用：查看单个 CPU 核心的负载情况，避免 “整体 CPU 不高，但某核心 100% 占用” 的隐藏问题（多线程程序设计不合理易出现）。
- 常用命令：
mpstat -P ALL 2 3（每 2 秒输出一次，共 3 次，-P ALL显示所有核心）。 - 调优思路：若某核心
%usr持续 100%，而其他核心空闲，说明程序 “线程亲和性” 差，可通过taskset命令将进程绑定到多个核心（如taskset -c 0-3 12345，将 PID12345 的进程绑定到 0-3 核心）。
3. pidstat：定位进程内的高耗 CPU 线程
- 作用：当
top发现某进程占 CPU 高时，用pidstat进一步查看该进程内的线程负载，精准定位 “问题线程”。 - 常用命令：
pidstat -t -p 12345 1 2（-t显示线程，-p 12345指定进程 PID，每 1 秒输出 2 次）。 - 实战步骤：
top找到高 CPU 进程 PID（如 12345）；pidstat -t -p 12345找到该进程内高 CPU 线程 TID（如 12346）；printf "%x " 12346将 TID 转为十六进制；jstack 12345 | grep 303a（十六进制 TID），查看线程堆栈，定位代码层面的问题（如死循环、频繁 GC）。
二、内存性能：避免 “内存泄漏” 与 “缓存滥用”
内存不足会导致服务器频繁 “swap 交换”（将内存数据写入磁盘），速度骤降。核心是判断 “内存是否真的不够”，还是 “缓存占用过多”。
1. free：快速查看内存使用情况
- 作用：显示总内存、已用内存、空闲内存、缓存（buffer/cache）占用，是内存排查的 “入门命令”。
- 常用命令：
free -h（-h以人类可读单位显示，如 GB/MB，避免看数字串）。 - 关键指标解读：
- 重点看
available（可用内存，含空闲内存 + 可回收缓存），若available持续低于总内存的 10%，才是真的内存不足； buffer/cache是系统缓存（如磁盘读写缓存），占用高是正常的，内存紧张时系统会自动回收，无需手动清理。
- 重点看
- 避坑点：别看到
used内存高就慌，先看available，很多时候是缓存占用，而非业务进程消耗。
2. vmstat：监控内存交换与页面活动
- 作用：查看内存与磁盘的交互（swap 交换）、页面调入调出（page in/out），判断是否因内存不足导致 “swap 风暴”。
- 常用命令：
vmstat 2 5（每 2 秒输出一次，共 5 次）。 - 关键指标解读：
si（每秒从 swap 读入内存的大小）、so（每秒写入 swap 的大小），正常应接近 0，若持续 > 0，说明内存不足，需扩容或优化进程内存占用；pi（每秒页面调入，从磁盘读入内存），过高可能是程序频繁访问磁盘数据，可通过缓存优化（如 Redis 缓存热点数据）。
3. pmap：分析单个进程的内存占用明细
- 作用：当某进程内存占用异常高时，用
pmap查看其内存分配情况，判断是否有 “内存泄漏”（如进程内存持续增长不释放）。 - 常用命令：
pmap -x 12345（-x显示详细内存信息，12345为进程 PID）。 - 调优思路：若进程内存中
Anonymous（匿名内存，无文件关联）持续增长，可能是代码内存泄漏，需通过valgrind等工具排查；若Shared（共享内存）过高，检查是否有重复加载的共享库，优化加载逻辑。
三、磁盘 IO：解决 “读写卡顿”，提升存储效率
磁盘是服务器的 “仓库”，IO 性能直接影响数据库、日志存储等业务。核心是找到 “IO 密集型进程”，优化读写策略。
1. iostat：监控磁盘 IO 负载与吞吐量
- 作用：显示磁盘的读写速度、IO 等待时间，判断磁盘是否 “忙不过来”。
- 常用命令：
iostat -x 2 3（-x显示扩展统计信息，每 2 秒输出 3 次）。 - 关键指标解读：
%util（磁盘 IO 利用率，正常应≤70%，持续 100% 说明磁盘满负荷，需换 SSD 或优化读写）；rMB/s（每秒读吞吐量）、wMB/s（每秒写吞吐量），结合业务判断是否超出磁盘性能上限（如机械硬盘读约 100MB/s，SSD 约 500MB/s）；await（IO 请求平均等待时间，正常应≤10ms，过高说明 IO 队列过长，需优化磁盘调度算法或减少 IO 请求）。
2. iotop：定位 “吃 IO” 的进程 / 线程
- 作用：类似
top，但专门显示进程的 IO 占用情况，快速找到 “频繁读写磁盘的进程”。 - 常用命令：
iotop -oP（-o只显示有 IO 活动的进程，-P显示进程 PID，不显示线程）。 - 实战场景：发现
%util100%，iotop看到mysql进程写 IO 占 90%，检查后发现是数据库慢查询导致频繁写 binlog，优化 SQL 后 IO 负载降至 30%。
3. df/du：排查磁盘空间不足问题
- 作用：
df查看磁盘分区使用率，du查看目录 / 文件大小，解决 “磁盘满导致服务崩溃” 的问题。 - 常用命令：
df -h：快速查看各分区使用率，若某分区Use%≥90%，需清理；du -sh /var/log/*：查看/var/log下各日志文件大小，找到过大的日志（如nginx.log达 100GB），删除或切割（logrotate配置日志轮转）。
- 调优技巧：将日志、数据库等 IO 密集型数据放在独立磁盘（如 SSD），避免与系统盘共用，减少 IO 竞争。
四、网络性能：排查 “延迟高”“丢包”，保障服务连通性
网络问题会导致 “服务访问超时”“数据传输中断”，核心是判断 “网络瓶颈在本地还是外部”，定位异常连接。
1. iftop：实时监控网络带宽占用
- 作用：类似
top，按连接显示网络带宽使用情况，快速找到 “占用带宽过高的 IP / 端口”（如异常的下载进程、DDoS 攻击）。 - 常用命令：
iftop -i eth0（-i eth0指定监控的网卡，默认监控所有网卡）。 - 关键指标解读：
- 左侧为连接的 IP 和端口，中间为实时带宽（
Rx接收，Tx发送），右侧为总流量； - 若某 IP 的
Tx持续 100Mbps+，且非业务 IP，可能是服务器被用作 “肉鸡” 发送数据，需封禁该 IP。
- 左侧为连接的 IP 和端口，中间为实时带宽（
2. netstat/ss：查看网络连接状态，排查 “连接泄漏”
- 作用：查看 TCP/UDP 连接状态，判断是否有 “连接数过多”“TIME_WAIT 状态堆积” 等问题（Web 服务、数据库易出现）。
- 常用命令：
ss -tan | grep :80 | wc -l：统计 80 端口的 TCP 连接数（-tan显示 TCP 连接，a显示所有状态，n显示 IP 端口）；ss -tan | grep TIME_WAIT | wc -l：统计 TIME_WAIT 状态的连接数，过高（如 > 1 万）会占用端口资源，需优化内核参数（如net.ipv4.tcp_tw_reuse = 1，允许复用 TIME_WAIT 连接）。
- 调优思路：若
ESTABLISHED（已建立连接）过多，检查业务是否有 “连接未关闭” 的问题（如代码未释放数据库连接）；若LISTEN状态的端口无服务，及时关闭，避免安全风险。
3. ping/traceroute：排查网络延迟与丢包
- 作用：
ping测试与目标 IP 的连通性和延迟，traceroute定位网络中断的节点（判断是本地网络、运营商还是目标服务器问题）。 - 常用命令：
ping -c 10 baidu.com（-c 10发送 10 个数据包，查看loss%（丢包率，正常 0%）、time（平均延迟，国内正常 < 50ms））；traceroute baidu.com：显示数据包从本地到百度的路由节点，若某节点延迟骤升或丢包，说明该节点有问题（如运营商路由故障）。
五、性能调优：从 “排查” 到 “解决” 的实战思路
掌握命令后，更重要的是形成 “定位 - 分析 - 优化” 的闭环，以下是 3 个高频场景的完整调优流程：
场景 1：CPU 负载高（us>90%）
top按P排序，找到高 CPU 进程 PID（如 12345）；pidstat -t -p 12345找到进程内高 CPU 线程 TID；- 若为业务进程：检查代码逻辑（如死循环、频繁计算），优化算法；
- 若为系统进程：如
kworker高，可能是内核 bug，升级内核版本。
场景 2：内存不足（si/so>0）
free -h确认available内存是否真的不足；pmap -x 12345分析高内存进程的内存分配；- 若为缓存占用：无需处理，系统会自动回收；
- 若为进程内存泄漏：修复代码，或重启进程临时缓解；
- 长期解决：升级服务器内存，或拆分进程（如将单 Java 服务拆分为多个微服务）。
场景 3：磁盘 IO 满（% util=100%）
iostat -x确认磁盘 IO 利用率，iotop找到高 IO 进程；- 若为日志写入：配置
logrotate轮转日志，压缩旧日志； - 若为数据库读写：
- 优化 SQL（如加索引减少全表扫描）；
- 开启数据库缓存（如 MySQL 的
innodb_buffer_pool_size设为内存的 50%-70%）； - 更换 SSD 磁盘，提升 IO 性能。
总结：Linux 性能优化的 “3 个原则”
- 先定位，再优化：别凭感觉调参（如盲目加内存、换 SSD），先用
top/iostat等命令找到瓶颈点，再针对性解决； - 优先软件优化，再硬件升级：多数性能问题是代码、配置不合理导致（如内存泄漏、SQL 慢查询），软件优化成本更低、效果更持久；
- 监控常态化：将核心指标（CPU us/sy、内存 available、磁盘 % util、网络延迟）加入监控系统（如 Prometheus+Grafana），提前预警，避免 “线上故障后才排查”。
本文地址：https://www.yitenyun.com/4586.html
下一篇：实用的记账工具
