第 5 期：系统监控与性能基石 —— 不装第三方软件也能看透一切

定位：中级目标：熟练使用 openEuler 自带工具（sysstat、bpftrace、/proc）定位 CPU 高 Load、内存泄漏、D 状态进程等经典问题；掌握 sysctl 持久化与 tuned 动态调优实验环境：任意 openEuler 虚拟机，建议 2C4G，可模拟 CPU 和内存压力

一、重新认识系统监控：不在多，在准

很多运维一上来就装 htop、glances、netdata，这些工具确实直观，但生产环境往往受限（无网络、安全合规、资源紧张）。而 openEuler 自带的 sysstat 工具集（默认已安装）和内核暴露的 /proc、/sys 接口，才是诊断问题的“第一性原理”。

核心原则：

用 sar 看历史趋势，用 iostat/mpstat 定位瞬时瓶颈。
用 /proc 下的数值验证直觉，用 bpftrace 下钻内核行为。

二、sysstat 工具集的核心用法

2.1 安装与配置

dnf install sysstat -y
systemctl enable --now sysstat   # 开启数据收集（默认每10分钟一次）

配置文件 /etc/sysconfig/sysstat 可修改采样间隔。生产建议：保留至少 7 天历史，用于复盘故障。

2.2 sar —— 全能历史记录器

实用技巧：当用户抱怨“昨天下午系统慢”，先执行：

sar -q -s 14:00 -e 16:00 | grep -v Average

若 ldavg-1 远超 CPU 核心数，说明是负载高；若 blocked 列不为 0，说明有进程在等待 I/O。

2.3 iostat —— 磁盘瓶颈定责

iostat -x 1 10
# -x 显示扩展指标，重点关注：
# %util：磁盘忙闲度（接近 100% 说明达到 I/O 上限）
# await：平均 I/O 等待时间（毫秒），超过 20ms 说明磁盘慢
# svctm：已被废弃，忽略

误区：%util 高不等于磁盘坏。对于 SSD，由于并行能力强，即使 %util 只有 50%，也可能达到性能瓶颈。应同时看 r_await/w_await。

2.4 mpstat —— 单核级 CPU 分析

mpstat -P ALL 1

若发现某个 CPU 的 %soft 异常高（如超过 30%），说明软中断分配不均（常见于网卡多队列未配置）。

三、/proc 和 /sys：系统的“内核寄存器”

直接读取这些文件，可以绕过任何上层工具得到最原始的数据。

3.1 CPU 信息

cat /proc/cpuinfo | grep "processor" | wc -l   # 逻辑核心数
cat /proc/stat | grep "^cpu"                    # 各核累计 tick

一个监控脚本片段：计算 5 秒内系统 CPU 使用率

old=$(grep '^cpu ' /proc/stat); sleep 5; new=$(grep '^cpu ' /proc/stat)
# 解析 user, nice, system, idle 等值，差值除以总时间

3.2 内存真相（别信 free 的 used 列）

cat /proc/meminfo | grep -E "^(MemTotal|MemFree|Cached|SReclaimable)"

MemAvailable（可用内存）比 MemFree 更准确，它包含了可回收的 page cache 和 slab。
内存泄漏的表现：MemAvailable 持续下降，但应用程序的 RSS 未明显增长（可能是内核模块泄漏）。

3.3 进程 D 状态分析

D 状态（不可中断睡眠）的进程通常卡在磁盘 I/O 或某些内核锁上。查看：

ps aux | awk '$8=="D" {print}'
cat /proc//stack          # 显示内核调用栈（需内核开启 debug 信息）
```

如果大量进程处于 D 状态，且 `iostat` 的 `await` 极高，大概率是存储系统故障（如 SAN 链路断开）。此时任何 `kill -9` 都无法杀死它们，只能重启或修复底层设备。

#### 3.4 /sys 调优入口

例如调整脏页刷回比例：

```bash
cat /sys/class/bdi/*/dirty_ratio
echo 5 > /sys/class/bdi/sda/dirty_ratio  # 降低 flush 触发阈值
```

（生产慎改，理解后再操作）

### 四、实战排障三例

#### 4.1 现象：CPU 低使用率（<20%）但 Load Average 高达 10

**解释**：Load 统计的是 **正在运行 + 不可中断睡眠** 的进程。低 CPU 使用率 + 高 Load → 大量进程 D 状态（I/O 阻塞）。

**步骤**：

1. `ps aux | awk '$8=="D" {print $2}'` 找到 D 状态进程 PID。
2. `cat /proc/<PID>/stack` 查看阻塞在内核哪个函数（通常是 `wait_on_page_locked` 或 `__lock_page`）。
3. 检查 `iostat -x 1` 看 `await` 是否数千毫秒 → 存储挂了。
4. 检查 `dmesg -T | tail -20` 看是否有 I/O 错误。

#### 4.2 现象：内存持续增长，swap 使用为 0，但 OOM killer 触发

**可能原因**：内核模块或 slab 泄漏（非用户态进程）。

**排查**：

- `slabtop -o` 按占用排序，观察 `dentry`、`inode_cache` 是否异常增长。
- 查看 `/proc/slabinfo` 比较重启前后某些对象数量。
- 如果 slab 增长与文件操作相关，检查是否有应用程序频繁打开关闭文件而不释放。

#### 4.3 现象：CPU 的 si（软中断）占用 50% 以上

**原因**：网卡单队列收发包过多，或某个中断号风暴。

**解决**：

1. `cat /proc/interrupts` 找到对应中断号（如 `eth0-rx-0`）。
2. `echo 1 > /proc/irq/<IRQ>/smp_affinity` 绑定到特定 CPU。
3. 如果网卡支持多队列，`ethtool -L eth0 combined 4` 开启多队列。

### 五、运维锦囊：sysctl 持久化与 tuned 调优

#### 5.1 sysctl 最佳实践

不要直接修改 `/proc/sys`（重启丢失）。正确持久化方式：

```bash
# 1. 写入 /etc/sysctl.d/99-custom.conf
cat > /etc/sysctl.d/99-custom.conf << EOF
# 提高并发连接追踪上限
net.netfilter.nf_conntrack_max = 1048576
# 允许端口重用（应对 TIME_WAIT 过多）
net.ipv4.tcp_tw_reuse = 1
# 避免掉队的 syncookies
net.ipv4.tcp_syncookies = 1
EOF

# 2. 立即生效
sysctl -p /etc/sysctl.d/99-custom.conf

注意：不要直接写 /etc/sysctl.conf，它已被 systemd-sysctl 废弃，应使用 /etc/sysctl.d/ 下的文件，按数字顺序加载。

5.2 tuned —— 自动化性能配置文件

tuned 可以动态调整内核参数、电源管理、磁盘调度器等，适应不同负载（高吞吐、低延迟、省电）。

dnf install tuned -y
systemctl enable --now tuned

# 查看可用配置
tuned-adm list

# 生产服务器推荐配置
tuned-adm profile throughput-performance    # 高吞吐
# 或 latency-performance                     # 低延迟（数据库、Redis）
# 或 virtual-guest                           # 虚拟机内的优化

# 验证当前配置
tuned-adm active
tuned-adm recommend

自定义调优集：复制 /usr/lib/tuned/throughput-performance 到 /etc/tuned/myprofile，修改 tuned.conf 后 tuned-adm profile myprofile。

六、bpftrace —— 内核动态追踪入门（高级运维必会）

bpftrace 是基于 eBPF 的前端工具，可以在不改动内核的情况下动态插桩，回答“为什么这个函数被调用了 10000 次”。

安装：dnf install bpftrace -y

示例 1：追踪系统中 openat 系统调用（打开文件）：

bpftrace -e 'tracepoint:syscalls:sys_enter_openat { printf("%s: %s\n", comm, str(args->filename)); }'

示例 2：统计某进程执行 read 的延迟分布：

bpftrace -e 'kprobe:vfs_read /pid == 12345/ { @start[tid] = nsecs; } kretprobe:vfs_read /@start[tid]/ { @us = hist((nsecs - @start[tid]) / 1000); delete(@start[tid]); }'

（输出直方图，看出大部分读延迟落在哪个区间）

对于没有安装 bpftrace 的环境，可以用 perf top 或 trace-cmd 作为低配替代。

七、实验指南

模拟高 Load 低 CPU：使用 dd if=/dev/zero of=/mnt/bigfile bs=1M count=1000 写入慢速磁盘（或用 scp 到 NFS），观察 mpstat 和 pidstat -d 1。
模拟内存 slab 泄漏：写一个脚本循环打开关闭文件而不 close（用 ulimit -n 限制），观察 slabtop 中 dentry 的变化。
实践 tuned：分别在 powersave 和 throughput-performance 下运行 sysbench cpu run，对比结果。

八、小结与下期预告

本期我们构建了一套“从 /proc 到 bpftrace”的性能知识链。掌握这些原生工具，你就不会被复杂的第三方工具绑架，在任何 Linux 环境（甚至故障现场）都能冷静分析。

下期预告：第 6 期《安全加固与 SELinux —— 理解规则而非无脑关闭》。我们会解释为什么 SELinux 不是敌人，openEuler 的国密支持如何使用，以及如何用 auditd 捕获恶意删除行为。

上期思考答案：inode64 会导致 inode 分配在文件系统任意位置，老内核（< 3.10）可能无法正确处理，并且某些 32 位程序调用 stat64 时会溢出。CentOS 6 内核 2.6.32 不支持 inode64，挂载会失败或导致文件系统损坏。

本期思考：当你执行 sar -q 看到 ldavg-1 为 8，blocked 为 0，而 mpstat 显示所有 CPU 的 %idle 为 90%，这说明了什么？下一步该检查什么？

场景	命令
查看 CPU 历史（今天）	`sar -u`
查看指定时间范围	`sar -u -s 10:00:00 -e 12:00:00`
查看内存（含缓存）	`sar -r`
查看 I/O 与进程队列	`sar -q` （关注 `ldavg-1` 和 `blocked`）
报告网络流量	`sar -n DEV 1 5`（实时 5 次）