机器层面性能排查应先从系统整体负载入手，按 CPU、内存、磁盘、网络的顺序逐层定位，适合生产环境出现响应变慢、资源告警时的快速止损场景。

环境准备与工具安装

大部分性能工具在生产环境最小化安装中可能缺失，建议提前确认或安装。部分命令需要 root 权限，请根据实际情况使用 sudo。

常用工具安装命令：

# CentOS/RHEL
sudo yum install -y sysstat net-tools iproute2 smartmontools

# Ubuntu/Debian
sudo apt-get install -y sysstat net-tools iproute2 smartmontools

注意：

• sysstat：提供 sar、iostat、mpstat 等核心监控命令。
• iproute2：提供 ss 命令，替代已废弃的 netstat。
• smartmontools：提供 smartctl，用于检查磁盘健康状态，需 root 权限。

命令速用版

以下是机器层面排查常用命令，可直接在 Linux 终端执行：

系统整体负载：

top  # 查看进程资源占用，按 P 键按 CPU 排序，按 M 键按内存排序
uptime  # 查看平均负载，三个值分别代表 1 分钟、5 分钟、15 分钟

CPU 检查：

mpstat -P ALL 1 5  # 查看每个 CPU 核心的使用率，关注%idle
lscpu  # 查看 CPU 架构、核心数、NUMA 分区信息

内存检查：

free -h  # 查看内存使用情况，关注 available 而非 free
vmstat 1 5  # 查看内存、swap、I/O 综合情况，关注 si/so

磁盘检查：

iostat -x 1 5  # 查看磁盘 I/O 使用率，关注%util 列（超过 80% 需警惕）
df -h  # 查看磁盘空间是否耗尽
sudo smartctl -i /dev/sdb  # 查看磁盘属性，确认型号、转速、健康状态（需 root）

网络检查：

ss -antp | grep 端口号  # 查看某个端口监听状态（替代 netstat）
ss -antp | awk "/^tcp/ {print \$6}" | sort | uniq -c | sort -nr | head  # 按状态统计 TCP 连接数
sar -n DEV 1 5  # 查看网卡流量和收发包数
ping 目标地址  # 查看网络延迟、抖动、丢包率
iftop  # 实时查看各 IP 的流量使用情况

为什么会这样

机器层面性能问题本质是硬件资源无法满足软件需求。现代服务器主要有四大硬件模块：CPU、内存、磁盘、网络，软件运行于硬件之上，硬件的小问题都可能给软件带来巨大影响。

CPU 硬件故障率较低，但 CPU 资源耗尽是常见性能瓶颈，通常由程序 bug 导致，比如死循环、线程争抢、上下文切换过多。内存问题常见于内存泄漏或配置不当，导致可用内存持续下降。磁盘是故障率和瓶颈率最高的部件，空间写满、I/O 请求过多、坏盘都会引发性能问题。网络问题涉及链路较长，排查时不仅要看本地机器指标，还要考虑延迟、抖动、丢包等因素。

排查顺序之所以推荐「CPU→内存→磁盘→网络」，是因为前两者检查成本低、命令响应快，而磁盘和网络问题往往需要更深入的链路分析。

分步处理

第一步：查看系统整体负载

使用 top 或 htop 命令查看系统平均负载。平均负载体现的是系统整体情况，是 CPU、内存、磁盘性能的综合反映。一般平均负载的值大于机器 CPU 核数时，说明机器资源已经紧张。

检查点：uptime 输出的三个负载值，如果 1 分钟值远高于 15 分钟值，说明负载在持续升高，需要警惕。

第二步：定位具体资源瓶颈

平均负载高后，需要确定是什么资源导致：

- CPU 问题：在 top 中看每个 CPU 核的使用情况，如果占比很高，瓶颈应该是 CPU，接着查看是什么进程导致

- 内存问题：用 free 查看内存使用情况，不直接看剩余多少，要结合 cache 和 buffer，然后用 top 排序查看具体进程占用

- 磁盘问题：用 iostat 查看磁盘 I/O 使用率，关注%util 列是否接近 100%（通常超过 80% 即视为高负载）

- 网络问题：用 iftop 查看流量是否超过机器给定带宽，用 ss 查看 TCP 连接数是否异常

第三步：深入检查可疑模块

如果磁盘有问题，检查 RAID 配置、使用 smartctl 获取磁盘属性、检测坏盘。RAID 之后的磁盘阵列情况如果不清楚，可以使用 MegaCli 查询（需特定硬件支持）。

如果网络有问题，查看端口占用、延迟、抖动、丢包信息、流量趋势和收发拒绝情况、链路状态、TCP 连接数。ss -antp | grep 进程 PID | awk "/^tcp/ {print \$6}" | uniq -c 可以按连接状态分类统计某个进程的 TCP 连接数，对排查连接数过多、不释放或半连接问题非常有效。

第四步：考虑外部系统

如果系统层各个指标查下来都没有发现异常，要考虑外部系统，比如数据库、缓存、存储等。性能问题的起点是日志，终点是业务，研发人员应是性能问题的第一负责人。

怎么验证是否生效

CPU 验证：调整后再次运行 mpstat 或 top，观察 CPU 使用率是否下降，负载平均值是否趋于稳定。

内存验证：运行 free -h 和 vmstat，观察 available 内存是否回升，swap 使用率是否下降。

磁盘验证：运行 iostat -x 1 5，观察%util 列是否降低，sar -dp 3 5 查看实时速率是否恢复正常。

网络验证：运行 ping 测试延迟和丢包率，观察 ifconfig 最后两行的 drop 关键字数量是否不再增长。ss 统计的连接数分布是否趋于合理。

业务验证：观察应用响应时间、吞吐量是否改善，错误率是否下降。如果有监控系统，查看 Grafana 或 Prometheus 上的性能指标曲线是否好转。

常见坑

1. 磁盘空间写满：生产上许多奇怪的问题可能是磁盘写满导致的，df -h 要作为常规检查项。

2. 内存判断误区：看 free 命令时不要只看剩余多少，要结合 cache 和 buffer，Linux 会把空闲内存用于缓存提升性能。

3. 连接未释放：ss 统计发现某进程建立大量网络连接，可能是连接未释放的 Bug，这是直接证据。

4. 丢包率忽视：ifconfig 显示的历史统计中包含 drop 关键字，如果丢包数量很大，需要确认网络是否有拥塞或其他异常。

5. CPU 问题根源：CPU 硬件故障率较低，但 CPU 资源耗尽是常见性能瓶颈，排查时要结合应用日志。

6. NUMA 影响：在个别系统架构上，NUMA 对业务性能影响较大，lscpu 可以查看 CPU 的 NUMA 分区情况。

7. 外部依赖：系统层指标正常但性能仍差，可能是数据库、缓存等外部系统问题，不要只盯着本机。

8. 权限不足：部分命令（如 smartctl、iostat 某些参数）需要 root 权限，普通用户执行可能报错或数据不全。