Linux 性能监控命令详解

以 iostat、vmstat 为核心，覆盖 CPU、内存、磁盘 I/O、进程与系统历史数据。适用于大多数 Linux 发行版。不同内核、发行版和 sysstat 版本的字段可能略有差异。

1. 快速索引

常用工具包安装：

# Debian / Ubuntu
sudo apt install sysstat procps

# RHEL / CentOS / Rocky / AlmaLinux
sudo dnf install sysstat procps-ng

iostat、mpstat、pidstat、sar 通常属于 sysstat；vmstat、free、top 通常属于 procps/procps-ng。

2. iostat：CPU 与块设备 I/O

2.1 用途

iostat 用于观察 CPU 使用情况及磁盘、SSD、云盘等块设备的吞吐量、请求队列和响应时间。它特别适合判断：

• I/O 请求是否过多；
• 磁盘响应是否变慢；
• 设备队列是否积压；
• 读写模式是大量小 I/O，还是少量大 I/O；
• CPU 是否因等待 I/O 而空转。

2.2 常用语法

iostat [选项] [采样间隔秒数] [输出次数]

推荐命令：

iostat -xz 1
iostat -xz 1 10
iostat -xk 1
iostat -xm 1
iostat -p ALL -xz 1

常用参数：

iostat -xz 1 中的 1 表示每秒采样一次。第一组数据通常是从开机至今的平均值，而非当前一秒；希望跳过它可使用 -y。

2.3 CPU 字段

注意：%iowait 高通常说明 I/O 值得调查，但它不是“磁盘利用率”，也不能单独证明磁盘就是瓶颈。CPU 很忙时，%iowait 甚至可能下降。

2.4 设备字段

不同版本可能使用不同名称，例如旧版的 avgqu-sz 在新版中常显示为 aqu-sz。

2.5 如何判断磁盘瓶颈

不要只看一个阈值，应同时观察：

1. 应用延迟是否同步升高；
2. await 或 r_await/w_await 是否明显高于该设备的正常基线；
3. aqu-sz 是否持续积压；
4. 吞吐或 IOPS 是否接近设备、云盘或存储套餐上限；
5. %util 是否长期较高；
6. vmstat 的 b、wa 是否同步升高；
7. 哪些进程正在产生 I/O，可用 pidstat -d 1 继续定位。

机械硬盘、SATA SSD、NVMe、网络云盘的合理延迟差异很大，因此不存在适用于所有设备的统一 await 阈值。应优先与同一机器的历史基线、厂商规格和应用 SLO 对比。

2.6 示例分析

Device   r/s   w/s  rkB/s  wkB/s  r_await  w_await  aqu-sz  %util
sda      5.0 420.0   80.0 6400.0     3.0     45.0    18.2   99.0

可能的判断：写请求远多于读请求，写延迟较高，队列明显积压且设备持续繁忙。下一步应运行 pidstat -d 1 找到主要写入进程，并检查是否达到设备 IOPS/吞吐上限。仅凭这一行仍不能判断根因是应用突发写入、存储限速、设备故障还是底层 RAID/云盘抖动。

3. vmstat：系统整体运行状态

3.1 用途

vmstat 在一张表中展示进程队列、内存、交换分区、I/O、系统调用和 CPU 状态，适合快速判断系统压力来自 CPU、内存还是 I/O。

推荐命令：

vmstat 1
vmstat 1 10
vmstat -w 1
vmstat -S M 1
vmstat -s

与 iostat 类似，vmstat 1 的第一行通常是开机以来的平均情况，后续行才代表每个采样间隔。

3.2 字段详解

procs：进程

r 是队列长度而不是 CPU 百分比。短暂高峰并不一定有问题，应观察是否持续及业务延迟是否受影响。

memory：内存

Linux 会主动用空闲内存做缓存，因此 free 很低不等于内存不足。应结合 free -h 的 available 和 vmstat 的 si/so 判断。

swap：交换活动

swpd 非零只说明曾经或当前使用了 swap；如果 si、so 长期接近 0，系统未必正在承受内存抖动。持续且大量换入换出通常会导致明显性能下降。

io：块设备 I/O

具体单位受实现和显示选项影响。精确分析设备吞吐与延迟时，应改用 iostat -xz 1。

system：内核活动

高 cs 不一定有问题，应与机器规模和历史值比较。线程数过多、锁竞争、频繁唤醒或大量短任务都可能提高上下文切换率。

cpu：CPU 时间分布

3.3 常见模式

4. mpstat：逐 CPU 核心观察

mpstat 用于判断整体 CPU 是否忙、压力是否集中在少数核心，以及虚拟机是否受到 CPU steal 影响。

mpstat 1
mpstat -P ALL 1
mpstat -P ALL 1 10

重点字段：

• %usr：用户态负载；
• %sys：内核态负载；
• %iowait：等待 I/O 的空闲时间；
• %irq、%soft：硬中断、软中断消耗；
• %steal：被宿主机抢占的时间；
• %idle：空闲时间。

若总 CPU 看似有余量，但某一个核心 %idle 长期接近 0，可能存在单线程瓶颈、CPU 亲和性限制、热点中断或应用分片不均。

5. pidstat：定位具体进程和线程

pidstat 可按时间连续统计每个进程或线程的 CPU、内存、I/O 和上下文切换情况，比反复读取 top 更适合记录和对比。

# CPU
pidstat -u 1

# 内存和缺页
pidstat -r 1

# 磁盘 I/O
pidstat -d 1

# 上下文切换
pidstat -w 1

# 综合显示，包含所有进程
pidstat -dur -p ALL 1

# 查看指定 PID 的线程
pidstat -t -p 1234 1

常见字段：

6. free：快速检查内存

free -h
free -h -s 1
free -w -h

重点字段：

排查时优先看 available，不要只看 free。还应结合 vmstat 1 的 si、so，以及内核是否触发 OOM：

journalctl -k | grep -iE 'oom|out of memory|killed process'

7. sar：查看当前和历史性能

sar 既能实时采样，也能读取由 sysstat 定时收集的历史数据。历史文件通常位于 /var/log/sa/ 或 /var/log/sysstat/。

# CPU
sar -u 1 10

# 内存
sar -r 1 10

# 负载与运行队列
sar -q 1 10

# 换页和 swap
sar -B 1 10
sar -W 1 10

# 块设备
sar -d -p 1 10

# 网络接口
sar -n DEV 1 10

# 读取某天的历史文件
sar -u -f /var/log/sa/sa14

若没有历史数据，应检查 sysstat 的定时采集服务是否已启用。不同发行版的启用方式和文件路径不同。

8. top 与常用交互操作

top
top -H -p 1234
top -b -n 1

进入 top 后常用按键：

负载平均值（load average）通常显示过去 1、5、15 分钟的平均可运行任务和不可中断任务数量。它不是 CPU 使用率。判断是否偏高时，应结合逻辑 CPU 数、vmstat 的 r/b 和业务响应时间。

9. 一套实用的排查顺序

9.1 先观察总体状态

uptime
vmstat 1 10
free -h

回答三个问题：CPU 是否饱和？是否存在持续换页？是否有大量任务阻塞？

9.2 展开 CPU

mpstat -P ALL 1 10
pidstat -u -w 1 10

判断是所有核心都忙、单核热点、内核开销、上下文切换，还是虚拟机 steal。

9.3 展开磁盘 I/O

iostat -xz 1 10
pidstat -d 1 10

将设备级的延迟、队列和吞吐与进程级读写对应起来。

9.4 展开内存

free -h
vmstat 1 10
pidstat -r 1 10

重点判断 available 是否过低、si/so 是否持续发生、哪些进程 RSS 或主缺页较高。

9.5 对照历史与业务时间线

sar -u
sar -q
sar -r
sar -d -p

把异常时间与发布、定时任务、备份、日志轮转、流量峰值、云盘突发额度耗尽等事件对齐。

10. 常见误区

1. 只看一次采样。 瞬时数据可能恰好处于峰值或低谷，建议至少连续观察 10～60 秒，并与历史基线比较。
2. 把首行当作实时值。 vmstat、iostat 的首行通常是开机以来的平均值。
3. 认为空闲内存少就是内存泄漏。 Linux 会用内存做缓存，优先看 available、换页活动和进程增长趋势。
4. 认为 %iowait 高就一定是磁盘坏了。 它只说明 CPU 空闲期间有未完成 I/O，还需结合设备延迟、队列、吞吐和应用行为。
5. 用统一阈值判断所有存储。 HDD、SSD、NVMe、RAID、网络盘和云盘特性差异很大。
6. 把 %util=100% 等同于设备绝对饱和。 对支持并行请求的现代设备，它的解释不如机械盘直接；应同时看延迟、队列和设备上限。
7. 忽略容器和虚拟化边界。 容器内看到的 CPU、内存和 I/O 可能受 cgroup 限额影响；虚拟机还要关注 %steal 和云平台指标。
8. 只看平均延迟。 平均值可能掩盖 P95/P99 长尾，最终应结合应用监控或存储侧延迟分位数。

11. 常用组合速查

# 系统总体状态，每秒一次
vmstat 1

# 所有活跃块设备的扩展指标，每秒一次
iostat -xz 1

# 所有 CPU 核心，每秒一次
mpstat -P ALL 1

# 各进程 CPU、内存、I/O，每秒一次
pidstat -dur -p ALL 1

# 内存概览
free -h

# 按 CPU 排序的实时进程视图
top

# 记录 60 秒数据，便于保存到日志或工单
vmstat -w 1 60
iostat -xz -y 1 60
mpstat -P ALL 1 60
pidstat -dur -p ALL 1 60

12. 磁盘、分区与文件系统故障排查

磁盘类问题至少要区分以下几类：容量耗尽、inode 耗尽、I/O 性能下降、文件系统只读或损坏、挂载异常、进程占用已删除文件、物理设备健康异常。

12.1 lsblk：查看块设备拓扑

lsblk 展示磁盘、分区、LVM、加密卷及挂载点之间的层级关系。

# 查看设备、文件系统、UUID、容量和挂载点
lsblk -f

# 自定义详细字段
lsblk -o NAME,KNAME,TYPE,SIZE,FSTYPE,FSVER,LABEL,UUID,MOUNTPOINTS,ROTA,RO,MODEL,SERIAL

# 仅显示指定设备及其子设备
lsblk /dev/sda

# JSON 格式，便于程序处理
lsblk -J -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS

常用参数和字段：

如果 df 中出现陌生设备，可先用 lsblk -f 将其映射到物理盘、分区、LVM 和挂载目录。

12.2 df：检查容量和 inode

# 各已挂载文件系统容量
df -hT

# inode 使用情况
df -ih

# 查询某个路径所在文件系统
df -hT /var/log

# 使用 POSIX 格式，脚本处理更稳定
df -P /var

重要判断：

• Use% 接近 100%：文件数据块可能耗尽；
• IUse% 接近 100%：inode 可能耗尽，即使仍有容量也无法创建新文件；
• df 和 du 相差很大：优先检查已删除但仍被进程打开的文件、挂载覆盖、稀疏文件、快照或文件系统保留空间；
• tmpfs 使用的是内存或 swap，不是普通磁盘空间。

12.3 du：定位空间被谁占用

# 当前目录下一级对象的占用量
du -xhd1 /var | sort -h

# 继续进入可疑目录
du -xhd1 /var/log | sort -h

# 查看某个目录总量
du -sh /var/lib

# 查看文件表面大小，而不是实际占用块数
du --apparent-size -sh /path

# 查找大文件；限制在同一文件系统
find /var -xdev -type f -size +1G -printf '%s %p\n' 2>/dev/null | sort -n

不要直接对 / 做无限深度扫描，生产环境上可能制造额外 I/O。建议先用 df 找到满的文件系统，再用 du -xhd1 逐层缩小范围。

12.4 find：按条件查找异常文件

# 同一文件系统内，大于 1 GiB 的普通文件
find /var -xdev -type f -size +1G -print

# 最近一天修改过的文件
find /var/log -xdev -type f -mtime -1 -print

# 最近 60 分钟修改过的文件
find /var/log -xdev -type f -mmin -60 -print

# 查找超过 30 天的普通日志；先只打印，不直接删除
find /var/log -xdev -type f -name '*.log' -mtime +30 -print

# 查找没有属主或属组的文件
find /srv -xdev \( -nouser -o -nogroup \) -ls

find ... -delete、-exec rm 属于破坏性操作。排障时应先输出清单、核对路径和备份策略，再决定是否清理。

12.5 findmnt 与 mount：检查挂载状态

# 树形展示所有挂载
findmnt

# 查询某个路径对应的挂载
findmnt -T /var/lib/app/data

# 查看某个设备挂载到哪里
findmnt -S /dev/mapper/vg-data

# 查看文件系统及挂载参数
findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS

# 检查 /etc/fstab 配置格式及可解析性
findmnt --verify

关键挂载参数：

发现文件系统突然变为 ro 时，应立即检查内核日志。内核可能因 I/O 错误或文件系统错误主动重新挂载为只读，以避免进一步损坏。

12.6 lsof 与 fuser：找占用文件或挂载点的进程

# 查找已删除但仍被进程打开的文件
sudo lsof +L1

# 查找谁打开了指定文件
sudo lsof /var/log/app.log

# 查找谁正在使用某个目录或挂载点
sudo fuser -vm /data

# 查找使用 TCP 8080 端口的进程
sudo lsof -nP -iTCP:8080
sudo fuser -v 8080/tcp

lsof +L1 中，链接数为 0 的文件虽然目录项已删除，但只要进程仍打开它，空间就不会释放。通常应让服务正常重新打开日志或重启对应服务；直接操作 /proc/PID/fd 有数据风险。

fuser -k 会向占用者发送信号，属于有影响的操作。排障阶段优先只用 -v 或 -m 查看，不要直接杀进程。

12.7 smartctl：检查 SATA/SAS 设备健康

smartctl 来自 smartmontools，用于读取硬盘或 SSD 的 SMART 健康信息。

# 完整信息
sudo smartctl -a /dev/sda

# 健康状态摘要
sudo smartctl -H /dev/sda

# 错误日志
sudo smartctl -l error /dev/sda

# 自检日志
sudo smartctl -l selftest /dev/sda

# 启动短自检；不会立即输出结果
sudo smartctl -t short /dev/sda

重点关注：

• Reallocated_Sector_Ct：重映射扇区；
• Current_Pending_Sector：待处理不稳定扇区；
• Offline_Uncorrectable：离线扫描无法修正的扇区；
• UDMA_CRC_Error_Count：链路 CRC 错误，可能与线缆、背板或控制器有关；
• 设备整体健康判断及错误日志。

厂商对 SMART 原始值的定义可能不同；云主机、硬件 RAID 后的逻辑盘也可能不透传 SMART。不要仅凭单个原始值判定设备一定损坏，应结合增长趋势、内核 I/O 错误和厂商文档。

12.8 nvme-cli：检查 NVMe 设备

# 列出 NVMe 设备和命名空间
sudo nvme list

# SMART / 健康日志
sudo nvme smart-log /dev/nvme0

# 控制器信息
sudo nvme id-ctrl /dev/nvme0

# 错误日志
sudo nvme error-log /dev/nvme0

重点字段包括 critical_warning、temperature、available_spare、percentage_used、media_errors、num_err_log_entries。percentage_used 是厂商估算的寿命消耗指标，不是磁盘空间使用率。

12.9 文件系统检查工具的安全边界

# 只读查看 ext 文件系统超级块信息
sudo tune2fs -l /dev/mapper/vg-data

# 只读检查 XFS 元数据
sudo xfs_repair -n /dev/mapper/vg-data

# ext 文件系统只检查，不自动修复
sudo fsck -n /dev/mapper/vg-data

fsck 或 xfs_repair 的实际修复通常要求文件系统卸载，并可能造成数据变化。生产环境不可在已读写挂载的文件系统上贸然修复，应先确认文件系统类型、备份、业务停机和恢复方案。

13. 网络故障排查

网络排障建议按以下顺序进行：接口与链路 → IP 地址 → 路由 → 邻居解析 → 监听端口 → TCP 状态 → DNS → 应用层请求 → 路径质量 → 抓包。

13.1 ip：接口、地址、路由和邻居

ip 是现代 Linux 网络排障的基础工具，替代了很多旧的 ifconfig、route、arp 用法。

# 接口和地址摘要
ip -br addr

# 详细链路状态和错误计数
ip -s link

# 查看路由表
ip route

# 查询访问目标地址实际会选择的路径和源地址
ip route get 8.8.8.8

# IPv6 路由
ip -6 route

# ARP / IPv6 邻居表
ip neigh show

# 网络命名空间列表
ip netns list

ip -s link 重点看 RX/TX errors、dropped、overrun、carrier。计数必须看增长趋势；历史累计值非零不代表当前仍异常。

ip route get <目标> 非常实用，它会给出选中的网关、出接口和源 IP，有助于排查多网卡、策略路由或回程路径问题。

查看策略路由：

ip rule show
ip route show table all

13.2 ethtool：网卡链路和驱动统计

# 链路速度、双工、自动协商及 Link detected
sudo ethtool eth0

# 网卡驱动和固件
sudo ethtool -i eth0

# 驱动级统计计数
sudo ethtool -S eth0

# offload 功能状态
sudo ethtool -k eth0

重点检查：

• Speed 是否符合预期；
• Duplex 是否为 Full；
• Link detected 是否为 yes；
• CRC、frame、missed、timeout、reset、drop 等计数是否持续增长；
• 驱动、固件版本是否与已知问题相关。

ethtool -K 会修改 offload 配置，可能影响性能和网络行为；除非为了受控验证且有回滚方案，否则不要在排障时随意关闭功能。

13.3 ss：套接字和 TCP 状态

ss 是查看监听端口、连接状态、队列和进程归属的首选工具。

# 所有 TCP/UDP 监听端口，显示进程，不解析域名和服务名
sudo ss -lntup

# 所有 TCP 连接
ss -ant

# 指定状态
ss -ant state established
ss -ant state time-wait
ss -ant state syn-recv

# 查看 8080 端口
sudo ss -lntp 'sport = :8080'

# 查看与目标地址有关的连接
ss -nt dst 10.0.0.8

# TCP 详细内部信息，包括拥塞算法、RTT 和重传
ss -tin

# 套接字统计摘要
ss -s

常用参数：

监听状态下：

• Recv-Q 通常表示等待应用 accept() 的已建立连接数；
• Send-Q 通常表示监听 backlog 上限；
• 队列长期接近上限可能说明应用 accept 太慢、线程阻塞或 backlog 配置不足。

连接状态下，Recv-Q 表示应用尚未读取的数据，Send-Q 表示已发送但尚未确认或尚未发出的数据。持续较大的队列可提示应用处理慢、对端处理慢或网络质量问题。

常见 TCP 状态：

13.4 nstat：TCP/IP 协议栈计数

# 查看当前内核网络计数
nstat

# 每秒刷新，仅显示发生变化的值
nstat -d 1

# 只查看 TCP 重传等相关项
nstat -az 'TcpRetransSegs|TcpExtTCPSynRetrans|IpInDiscards|UdpInErrors'

重点计数：

• TcpRetransSegs：TCP 重传段；
• TcpExtTCPSynRetrans：SYN 重传；
• TcpExtListenOverflows、TcpExtListenDrops：监听队列溢出或丢弃；
• IpInDiscards：IP 层丢弃；
• UdpInErrors、UdpRcvbufErrors：UDP 接收错误或缓冲区不足。

这些通常是开机以来的累计计数。排查时要观察单位时间内增量，并与实际流量规模比较。

13.5 ping：检查可达性和基础延迟

# 发送 5 个请求，每次等待最多 1 秒
ping -c 5 -W 1 10.0.0.1

# 每 0.2 秒一次；可能需要权限，且应控制使用范围
ping -c 20 -i 0.2 10.0.0.1

# 指定源接口
ping -I eth0 -c 5 10.0.0.1

# 探测不分片时可通过的包大小，常用于 MTU 问题
ping -M do -s 1472 -c 3 10.0.0.1

关键参数：

ping 不通不等于目标服务不可用，ICMP 可能被禁；ping 通也不等于 TCP 端口或应用正常。应继续用 nc、curl 或应用协议测试。

13.6 tracepath、traceroute 与 mtr：定位路径问题

# 无需特殊权限，兼顾路径和 MTU 信息
tracepath example.com

# ICMP 路由跟踪
traceroute -I example.com

# 使用 TCP 443 探测，更接近 HTTPS 流量
sudo traceroute -T -p 443 example.com

# 生成 100 次探测的报告
mtr -rwzc 100 example.com

# TCP 443 模式
sudo mtr -T -P 443 -rwzc 100 example.com

路由中间节点不响应或显示丢包，不一定代表它转发业务流量时也丢包。一些路由器会限制 ICMP 响应。只有当丢包从某一跳开始并持续到后续跳和最终目标时，才更像真实路径问题。

13.7 dig 与 resolvectl：DNS 排查

# 查询 A 记录并查看完整解析过程摘要
dig example.com

# 只输出答案
dig +short example.com

# 指定 DNS 服务器
dig @8.8.8.8 example.com A

# 查询 AAAA、MX、TXT
dig example.com AAAA
dig example.com MX
dig example.com TXT

# 从根服务器开始迭代跟踪
dig +trace example.com

# 反向解析
dig -x 8.8.8.8

# systemd-resolved 环境查看状态和实际 DNS
resolvectl status
resolvectl query example.com

重点看：

• status：NOERROR、NXDOMAIN、SERVFAIL、REFUSED；
• ANSWER SECTION：实际记录和值；
• Query time：DNS 响应时间；
• SERVER：真正回答查询的 DNS 服务器；
• TTL：缓存有效期。

应用的解析行为还可能受 /etc/hosts、/etc/nsswitch.conf、本地缓存和容器 DNS 配置影响。getent hosts example.com 更接近应用通过系统 NSS 获取结果的方式。

13.8 nc：测试 TCP/UDP 端口

# TCP 连接测试，3 秒超时，显示详细结果
nc -vz -w 3 example.com 443

# 测试端口范围
nc -vz -w 2 10.0.0.8 8000-8010

# UDP 探测；UDP 无握手，成功提示不一定证明服务响应
nc -vzu -w 2 10.0.0.53 53

13.9 curl：从应用层验证 HTTP/HTTPS

# 仅响应头
curl -I --connect-timeout 3 --max-time 10 https://example.com/

# 显示请求、TLS 和响应细节
curl -v --connect-timeout 3 --max-time 10 https://example.com/

# 丢弃响应体并输出各阶段耗时
curl -sS -o /dev/null \
  -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total} code=%{http_code}\n' \
  https://example.com/

# 绕过 DNS，将域名临时映射到指定地址；仍保留 Host 与 TLS SNI
curl --resolve example.com:443:10.0.0.8 https://example.com/

# 指定代理为空，排除环境代理影响
curl --noproxy '*' https://example.com/

关键参数：

耗时解读：DNS 高看解析链路；connect 增量高看 TCP 建连；tls 增量高看 TLS；首字节高通常看服务端处理、上游依赖或排队。

13.10 tcpdump：抓包验证事实

# 查看接口列表
sudo tcpdump -D

# 在任意接口抓取与目标主机 10.0.0.8 有关的数据，不解析名称
sudo tcpdump -i any -nn host 10.0.0.8

# 抓取 TCP 443，保存完整包到文件
sudo tcpdump -i eth0 -nn -s 0 -w /tmp/https.pcap 'tcp port 443'

# 只抓 1000 个包后自动结束
sudo tcpdump -i eth0 -nn -s 0 -c 1000 -w /tmp/sample.pcap 'host 10.0.0.8'

# 观察握手 SYN 或 RST
sudo tcpdump -i any -nn 'tcp[tcpflags] & (tcp-syn|tcp-rst) != 0'

# 抓 DNS
sudo tcpdump -i any -nn 'port 53'

常用参数：

抓包可能包含账号、Cookie、令牌、业务数据和内部地址。应最小化接口、主机、端口、时长和包数，安全保存并及时清理。高流量环境抓包也会带来 CPU、内存和磁盘开销。

14. 进程、线程与资源占用排查

14.1 ps：生成进程快照

# 常用全量进程视图
ps aux

# 自定义字段并按 CPU 降序
ps -eo pid,ppid,user,stat,ni,psr,%cpu,%mem,rss,vsz,etimes,comm,args --sort=-%cpu

# 按 RSS 降序取前 20 个进程
ps -eo pid,user,%mem,rss,etimes,comm,args --sort=-rss | head -20

# 查看指定 PID
ps -p 1234 -o pid,ppid,user,lstart,etimes,stat,ni,psr,%cpu,%mem,rss,vsz,args

# 查看指定进程的所有线程
ps -L -p 1234 -o pid,tid,psr,stat,%cpu,comm

# 森林形式显示父子关系
ps -ef --forest

关键字段：

常见 STAT：R 运行或可运行，S 可中断睡眠，D 不可中断睡眠，T 停止，Z 僵尸。附加标记如 l 表示多线程，+ 表示处于前台进程组。

D 状态通常与 I/O 或某些内核等待有关，不能用普通信号立即终止；应先找到其等待资源和底层故障。Z 状态不消耗正常运行资源，但说明父进程未回收子进程退出状态。

14.2 pstree、pgrep 与 pidof：理解进程关系

# 显示 PID 和父子树
pstree -ap

# 从指定 PID 开始展示
pstree -aps 1234

# 按进程名查 PID 和命令行
pgrep -af nginx

# 查指定用户的进程
pgrep -u appuser -af .

# 获取精确程序名对应 PID
pidof nginx

pgrep -f 会匹配完整命令行，可能连排障命令自身也匹配。执行后续信号操作前必须再次确认 PID。

14.3 top：进程和线程动态观察

除前文快捷键外，还可使用：

# 指定 PID
top -p 1234

# 指定 PID 并展示线程
top -H -p 1234

# 批处理模式，每秒采样，共 10 次，便于留证
top -b -d 1 -n 10

进程 %CPU 的口径因工具和模式而异。多线程进程在某些显示模式下可能超过 100%，表示使用了超过一个逻辑 CPU 的计算能力。

14.4 lsof：进程打开了什么

# 指定 PID 打开的所有对象
sudo lsof -p 1234

# 只看指定 PID 的网络连接
sudo lsof -nP -a -p 1234 -i

# 指定用户打开的文件
sudo lsof -u appuser

# 查看指定目录下被打开的对象；+D 会递归，目录大时开销高
sudo lsof +d /var/log/app

# 统计进程打开的描述符数量
sudo lsof -n -p 1234 | wc -l

lsof 的输出不仅是普通文件，还包括目录、库、管道、设备和套接字。精确计算文件描述符数量可直接查看 /proc/PID/fd，因为 lsof 还会显示其他映射对象。

14.5 /proc：直接检查进程状态

# 进程状态、线程数、RSS、上下文切换
cat /proc/1234/status

# 文件描述符数量
ls /proc/1234/fd | wc -l

# 文件描述符上限
cat /proc/1234/limits

# 原始命令行，以空格替换 NUL 分隔符
tr '\0' ' ' < /proc/1234/cmdline

# 环境变量可能包含密码或令牌，谨慎查看和保存
sudo tr '\0' '\n' < /proc/1234/environ

# 内存映射摘要
cat /proc/1234/smaps_rollup

# 进程 I/O 累计值
cat /proc/1234/io

# 等待位置和内核栈；权限及内核配置可能限制
cat /proc/1234/wchan
sudo cat /proc/1234/stack

smaps_rollup 中的 PSS 会按共享比例分摊共享页，比简单相加 RSS 更适合估算一个进程对物理内存的实际贡献。

14.6 strace：跟踪系统调用

strace 可判断进程卡在文件、网络、锁、睡眠还是其他系统调用。

# 附加到现有进程，显示时间和每次调用耗时
sudo strace -tt -T -p 1234

# 跟踪所有线程和子进程，写入文件
sudo strace -ff -tt -T -p 1234 -o /tmp/strace.out

# 只跟踪文件和网络相关调用
sudo strace -f -e trace=%file,%network -p 1234

# 汇总系统调用耗时和次数
sudo strace -f -c -p 1234

# 启动并跟踪一个命令
strace -f -o /tmp/command.strace command arg1

常用参数：

附加 strace 会改变目标进程时序并带来开销，高系统调用频率的生产进程尤其明显。跟踪内容还可能包含文件名、请求内容、密钥或个人数据，应缩小时间和过滤范围。

14.7 perf：CPU 热点和调度分析

# 系统级实时热点
sudo perf top

# 对指定 PID 采样 30 秒
sudo perf record -F 99 -g -p 1234 -- sleep 30
sudo perf report

# 统计命令的 CPU 周期、指令、缓存缺失和上下文切换
perf stat -d command arg1

# 系统级调度统计，持续 10 秒
sudo perf sched record -- sleep 10
sudo perf sched timehist

调用栈质量受调试符号、编译选项、帧指针和内核权限限制影响。perf 也会产生开销，长时间或高频采样前应评估影响。

14.8 pmap：查看进程内存映射

# 显示扩展内存映射和汇总
pmap -x 1234

# 显示更详细映射；支持情况依 procps 版本而异
pmap -XX 1234

pmap 可帮助识别匿名内存、堆、共享库和内存映射文件。若要更准确地区分共享内存，应结合 /proc/PID/smaps_rollup 的 PSS。

14.9 文件描述符与系统上限

# 当前 shell 的软限制
ulimit -n

# 指定进程限制
grep -i 'open files' /proc/1234/limits

# 系统文件句柄：已分配、未使用、最大值
cat /proc/sys/fs/file-nr

# systemd 服务最终生效的限制
systemctl show app.service -p LimitNOFILE

# 统计进程 FD，并观察是否随时间增长
ls /proc/1234/fd | wc -l

出现 Too many open files 时，要区分进程自身软/硬限制和系统级上限。单纯提高限制可能掩盖连接或文件句柄泄漏，应该同时观察 FD 类型和增长趋势。

14.10 信号与进程终止的安全顺序

# 查看可用信号
kill -l

# 请求进程正常退出
kill -TERM 1234

# 让部分服务重新加载配置；是否支持取决于程序
kill -HUP 1234

# 强制终止，进程无法执行清理逻辑
kill -KILL 1234

应优先使用服务管理器执行正常停止，例如 systemctl stop app.service。SIGKILL 可能导致事务中断、临时文件残留或数据损坏，只应作为确认普通终止无效后的最后手段。

15. 系统日志、内核与服务排查

15.1 journalctl：查询 systemd 日志

# 本次启动以来的日志
journalctl -b

# 上一次启动的日志
journalctl -b -1

# 指定服务，持续跟踪
journalctl -u app.service -f

# 最近 30 分钟指定服务日志
journalctl -u app.service --since '30 min ago'

# 指定时间范围
journalctl --since '2026-08-14 09:00:00' --until '2026-08-14 10:00:00'

# 仅内核日志
journalctl -k -b

# 本次启动中 error 及以上级别
journalctl -b -p err

# 反向显示，最新日志在前
journalctl -r -n 100

# 查看占用空间
journalctl --disk-usage

优先级从严重到轻微通常为：emerg、alert、crit、err、warning、notice、info、debug。-p err 会包含 err 及更严重等级。

日志可能包含敏感数据。导出到工单前，应检查令牌、用户信息、内部地址和业务载荷。

15.2 dmesg：查看内核环形缓冲区

# 易读时间和级别
sudo dmesg -T -L

# 仅 warning 及以上
sudo dmesg --level=emerg,alert,crit,err,warn

# 持续跟踪新内核消息
sudo dmesg -wT

# 搜索常见硬件、文件系统和 OOM 问题
sudo dmesg -T | grep -iE 'error|fail|timeout|reset|I/O|ext4|xfs|nvme|oom|out of memory'

dmesg -T 的墙钟时间是根据当前时间换算，系统时钟调整后可能不完全准确；与事故时间线对齐时，journalctl -k -o short-precise 通常更合适。

15.3 systemctl：检查服务状态和依赖

# 服务状态及最近日志
systemctl status app.service

# 查看失败单元
systemctl --failed

# 判断是否正在运行、是否开机启用
systemctl is-active app.service
systemctl is-enabled app.service

# 查看服务的完整生效配置
systemctl cat app.service
systemctl show app.service

# 查看依赖关系
systemctl list-dependencies app.service

# 查看启动耗时
systemd-analyze blame
systemd-analyze critical-chain

常见状态：

• active (running)：服务运行中，但不代表业务一定健康；
• active (exited)：启动动作成功退出，常见于 oneshot 服务；
• failed：启动或运行失败；
• activating：启动尚未完成；
• deactivating：正在停止。

restart、stop、daemon-reload 都会改变系统状态。查看和诊断阶段先用 status、show、cat、journalctl，确认影响后再操作。

15.4 uptime、w、who、last：负载与登录事件

uptime
w
who -b
last -x | head -30

• uptime：运行时长和 1/5/15 分钟负载；
• w：登录用户、来源、空闲时间和正在执行的命令；
• who -b：最近启动时间；
• last -x：登录、注销、重启、关机和运行级别记录。

系统意外重启时，可用 last -x 确认时间，再看 journalctl -b -1 -e 和上一次启动的内核日志。

15.5 sysctl：查看内核运行参数

# 查看单个参数
sysctl vm.swappiness
sysctl net.core.somaxconn
sysctl net.ipv4.ip_local_port_range

# 查看所有参数；输出很大
sysctl -a

# 查看持久化配置来源
grep -R --line-number 'somaxconn' /etc/sysctl.conf /etc/sysctl.d 2>/dev/null

sysctl -w 会立即修改运行参数，错误值可能造成网络中断、内存异常或安全风险。排障文档中建议先只读检查；修改前要理解作用域、持久化位置和回滚值。

16. CPU、内存与内核压力的补充工具

16.1 slabtop：内核 slab 缓存

sudo slabtop
sudo slabtop -o

当普通进程 RSS 解释不了内存消耗，而 /proc/meminfo 中 Slab 或 SUnreclaim 很高时，可用 slabtop 查找占用最大的内核对象缓存。结果需要结合内核版本、工作负载和增长趋势判断。

16.2 /proc/meminfo：完整内存拆分

cat /proc/meminfo
grep -E 'MemTotal|MemAvailable|Swap|Cached|Buffers|Slab|SReclaimable|SUnreclaim|Dirty|Writeback|AnonPages|PageTables|Huge' /proc/meminfo

关键字段：

16.3 pressure stall information：PSI 压力指标

现代 Linux 可通过 PSI 判断任务因 CPU、内存或 I/O 资源不足而停顿的时间比例。

cat /proc/pressure/cpu
cat /proc/pressure/memory
cat /proc/pressure/io

示例格式：

some avg10=2.10 avg60=1.20 avg300=0.40 total=123456
full avg10=0.50 avg60=0.20 avg300=0.10 total=23456

• some：至少有一个任务因该资源而停顿；
• full：所有非空闲任务同时停顿，通常代表更严重的资源饥饿；
• avg10、avg60、avg300：过去 10、60、300 秒停顿时间比例；
• CPU 压力通常只有 some，因为只要有任务在运行就不是全部停顿。

PSI 比单纯利用率更直接地反映资源竞争是否实际阻塞任务，但仍应与应用延迟、cgroup 限制和其他系统指标结合。

16.4 dstat、atop 和 htop

• htop：更友好的交互式进程、线程、CPU 与内存视图；
• atop：可记录并回放历史进程级 CPU、内存、磁盘和网络活动；
• dstat：将多类资源指标并排显示，但部分发行版已不再默认维护或提供，可使用兼容替代品。

示例：

htop
atop
atop -r /var/log/atop/atop_20260814
dstat -tcdnm --top-cpu --top-mem --top-io 1

历史记录是否存在取决于是否提前启用了采集服务。

17. 分场景故障排查清单

17.1 磁盘空间满

df -hT
df -ih
findmnt -T /疑似目录
du -xhd1 /疑似挂载点 | sort -h
sudo lsof +L1

依次确认数据块、inode、目录占用、已删除仍占用文件。不要在根目录盲目删除，也不要把压缩日志当作唯一长期方案。

17.2 磁盘慢或 I/O wait 高

vmstat 1 10
iostat -xz -y 1 10
pidstat -d 1 10
cat /proc/pressure/io
journalctl -k -b -p warning

先证明有持续等待，再定位设备和进程，最后检查内核错误、设备健康、云盘额度及应用 I/O 模式。

17.3 CPU 高

uptime
vmstat 1 10
mpstat -P ALL 1 10
pidstat -u -w 1 10
ps -eo pid,ppid,stat,psr,%cpu,%mem,comm,args --sort=-%cpu | head -30

分清用户态、内核态、单核热点、运行队列、虚拟机 steal 和上下文切换，再决定是否需要 perf 或应用级分析器。

17.4 内存持续增长或 OOM

free -h
vmstat 1 10
grep -E 'MemAvailable|Swap|AnonPages|Slab|SUnreclaim|PageTables' /proc/meminfo
pidstat -r 1 10
ps -eo pid,user,rss,vsz,%mem,etimes,comm,args --sort=-rss | head -30
journalctl -k -b | grep -iE 'oom|out of memory|killed process'

区分匿名内存、页缓存、slab、页表、共享内存和 cgroup 限制。宿主机仍有内存时，容器也可能因自己的内存上限触发 OOM。

17.5 服务无法启动

systemctl status app.service
journalctl -u app.service -b -n 200 --no-pager
systemctl cat app.service
systemctl show app.service
ss -lntup
df -hT
df -ih

常见原因包括配置错误、权限、端口冲突、依赖未就绪、工作目录或文件不存在、磁盘/inode 满、资源限制和安全策略拦截。

17.6 端口无法访问

服务端：

systemctl status app.service
sudo ss -lntp 'sport = :8080'
ip -br addr
ip route
sudo tcpdump -i any -nn 'tcp port 8080'

客户端：

getent hosts server.example.com
ip route get 10.0.0.8
nc -vz -w 3 10.0.0.8 8080
curl -v --connect-timeout 3 --max-time 10 http://10.0.0.8:8080/

抓包中只看到客户端重复 SYN、服务端完全收不到：查中间路由、安全组和防火墙；服务端收到 SYN 但不回 SYN-ACK：查监听、内核策略和回程路由；握手完成但应用无响应：查应用线程、连接池和上游依赖。

17.7 DNS 解析异常

cat /etc/resolv.conf
grep '^hosts:' /etc/nsswitch.conf
resolvectl status
getent hosts example.com
dig example.com
dig @指定DNS服务器 example.com

比较系统 NSS 结果与直接 DNS 查询结果，检查 search domain、缓存、split DNS、容器 DNS 以及 A/AAAA 双栈差异。

17.8 进程卡死或无响应

ps -p 1234 -o pid,ppid,stat,wchan:32,%cpu,%mem,etimes,args
top -H -p 1234
pidstat -t -p 1234 -u -w 1
sudo cat /proc/1234/stack
sudo strace -ff -tt -T -p 1234 -o /tmp/strace.out

若进程处于 D 状态，重点看 I/O、网络文件系统和内核等待；若 CPU 高，使用线程视图和采样分析；若处于睡眠，检查系统调用、锁、连接池或上游等待。

17.9 文件描述符耗尽

grep -i 'open files' /proc/1234/limits
ls /proc/1234/fd | wc -l
sudo lsof -nP -p 1234
cat /proc/sys/fs/file-nr
ss -s

确认是文件、socket、pipe 还是其他描述符增长。应优先修复泄漏或连接生命周期问题，再评估是否提高限制。

17.10 系统突然重启

last -x | head -30
journalctl --list-boots
journalctl -b -1 -e
journalctl -k -b -1

检查 OOM、kernel panic、watchdog、硬件错误、掉电、人工重启和云平台事件。日志在异常掉电前可能来不及持久化，还需结合 BMC、宿主机或云平台事件记录。

18. 排障取证建议

1. 先记录准确时间、时区、主机名、业务现象和影响范围。
2. 优先执行只读命令，避免重启、清缓存或杀进程破坏现场。
3. 连续采样并保留原始输出，不要只截取一个瞬时值。
4. 同时收集系统指标、应用日志和上游/下游依赖状态。
5. 对照正常时段基线，关注变化率而不只是绝对值。
6. 输出中若包含命令行参数、环境变量、请求头、抓包或日志，分享前必须脱敏。
7. 为命令加超时、次数和范围，避免 du、find、lsof +D、抓包等诊断本身造成负载。
8. 修改配置前记录原值、预期效果和回滚步骤；修复后用相同指标验证。

可用于快速留存基础现场信息的只读命令组合：

date -Ins
hostnamectl
uptime
free -h
vmstat -w 1 10
mpstat -P ALL 1 10
iostat -xz -y 1 10
pidstat -dur -p ALL 1 10
df -hT
df -ih
ip -br addr
ip -s link
ip route
ss -s
sudo ss -lntup
systemctl --failed
journalctl -b -p err -n 200 --no-pager

19. 平台差异

• 本文以 Linux 上的 sysstat 和 procps-ng 实现为准。
• macOS 也提供名为 iostat 和 vm_stat 的工具，但参数和输出字段与 Linux 不同，不能直接照搬本文命令。
• BusyBox 或精简容器中的同名命令可能只支持部分参数。
• 使用 man iostat、man vmstat 或命令的 --help，可确认当前机器实际支持的字段与参数。