Linux系统性能优化与监控

系统性能优化与监控是保障 Linux 服务器稳定运行的核心技术，涉及 CPU、内存、磁盘 I/O、网络、进程 等多维度的指标分析、问题定位与优化策略。以下从监控工具与指标、常见问题诊断、优化方法三个层面详细讲解，并结合实战案例说明。

一、性能监控的核心指标与工具

要优化系统性能，首先需要明确“哪些指标异常”，再定位“异常的原因”。以下是各维度的核心监控指标及常用工具。

1. CPU 性能监控

CPU 是系统的“大脑”，其性能瓶颈通常表现为 高负载（Load Average）、高使用率（User/Sys） 或 中断风暴。

(1) 核心监控指标

Load Average（平均负载）：表示单位时间内处于 运行（Running） 或 等待运行（Runnable） 状态的进程数（包括等待 I/O 的进程）。
- 通常关注 1 分钟（1m）、5 分钟（5m）、15 分钟（15m）的平均值。
- 理想状态：1m ≈ 5m ≈ 15m，且不超过 CPU 核心数（如 4 核 CPU，负载不超过 4 为健康）。
CPU 使用率（Usage）：
- User%：用户进程占用 CPU 的比例（正常应占大部分）。
- System%：内核进程占用 CPU 的比例（过高可能意味着系统调用频繁或中断过多）。
- Idle%：CPU 空闲比例（过低说明 CPU 繁忙）。
- IOWait%：CPU 等待 I/O 完成的时间比例（过高说明磁盘 I/O 是瓶颈）。
上下文切换（Context Switch）：进程切换导致的 CPU 时间消耗（过高可能因进程过多或调度频繁）。

(2) 监控工具与示例

top/htop：实时查看进程 CPU 占用。
```
top -d 1  # 每 1 秒刷新一次
```
输出关键列：
- PID：进程 ID。
- USER：进程所有者。
- %CPU：CPU 使用率。
- COMMAND：进程名称。
示例：发现 mysql 进程占用 80% CPU，需进一步分析其查询是否低效。
mpstat：细粒度分析 CPU 各核心的使用率（适合多核服务器）。
```
mpstat -P ALL 1  # 每 1 秒输出所有 CPU 核心的统计
```
输出关键列：
- %usr：用户态 CPU 使用率。
- %sys：内核态 CPU 使用率。
- %idle：空闲率。
示例：某核心 %idle 持续低于 10%，说明该核心负载过高。

pidstat：定位具体进程的 CPU 消耗。

pidstat 1  # 每 1 秒输出所有进程的 CPU 使用率
pidstat -p 1234 1  # 监控 PID 为 1234 的进程

2. 内存性能监控

内存是系统的“临时仓库”，性能问题通常表现为 内存不足（OOM）、Swap 频繁使用 或 内存泄漏。

(1) 核心监控指标

可用内存（Free）：未被使用的物理内存（过低可能导致系统使用 Swap）。
缓存（Cache）与缓冲（Buffer）：内核用于加速磁盘 I/O 的内存（合理利用可提升性能，但过多可能挤占应用内存）。
Swap 使用率：Swap 分区被使用的比例（过高说明物理内存不足）。
内存泄漏（Memory Leak）：进程持续占用内存且不释放（表现为可用内存持续下降）。

(2) 监控工具与示例

free -h：查看内存使用概况（-h 表示人性化单位）。
```
free -h
```
输出关键列：
- Mem：物理内存。
  - total：总内存。
  - used：已使用内存（不包含缓存/缓冲）。
  - free：空闲内存。
  - buff/cache：缓存/缓冲内存。
- Swap：交换分区。
示例：free 列接近 0，buff/cache 占用高，说明应用内存不足但内核缓存占用过多。
vmstat：监控内存、Swap、I/O 等综合指标。
```
vmstat 1  # 每 1 秒刷新一次
```
输出关键列：
- si（Swap In）：从 Swap 读取到内存的数据量（持续 >0 说明物理内存不足）。
- so（Swap Out）：从内存写入 Swap 的数据量（持续 >0 说明物理内存不足）。
- cache：缓存内存大小。
- buff：缓冲内存大小。
示例：si 和 so 持续大于 1000，说明 Swap 频繁交换，需增加物理内存。
pmap：查看进程的内存映射（定位大内存进程或内存泄漏）。
```
pmap -x <PID>  # 显示 PID 进程的详细内存占用
```
示例：发现某 Java 进程 pmap 输出中 RSS（实际驻留内存）持续增长，可能存在内存泄漏。

3. 磁盘 I/O 性能监控

磁盘 I/O 是系统的“瓶颈大户”，性能问题通常表现为 高延迟（Latency）、低吞吐量（Throughput） 或 磁盘队列过长。

(1) 核心监控指标

%util：磁盘忙于 I/O 的时间比例（接近 100% 说明磁盘已满负荷）。
await：I/O 请求的平均等待时间（包括队列等待和磁盘处理时间，单位 ms）。
svctm：磁盘处理 I/O 请求的平均时间（不包括队列等待，单位 ms）。
r/s/w/s：每秒读/写次数（IOPS）。
队列长度（avgqu-sz）：等待处理的 I/O 请求数（过高说明磁盘处理不过来）。

(2) 监控工具与示例

iostat：查看磁盘 I/O 统计（需安装 sysstat 包）。
```
iostat -dx 1  # -d 显示磁盘，-x 显示扩展指标，每 1 秒刷新
```
输出关键列（以 sda 磁盘为例）：
- %util：磁盘利用率（>80% 需警惕）。
- await：I/O 平均等待时间（机械盘正常约 5-15ms，SSD 约 1-5ms）。
- svctm：磁盘处理时间（机械盘约 3-10ms）。
- r/s/w/s：读写 IOPS（机械盘约 100-200，SSD 可达数万）。
示例：sda 的 %util=95%，await=50ms，说明磁盘已严重瓶颈。
iotop：实时查看进程的 I/O 读写速率（需 root 权限）。
```
iotop -o  # 仅显示有 I/O 活动的进程
```
输出关键列：
- WRITE/READ：进程的写/读速率（KB/s）。
- DISK READ/DISK WRITE：磁盘实际的读写速率。
示例：发现 mysql 进程 WRITE 速率为 500MB/s，远超磁盘上限，需优化 SQL 减少写操作。
dstat：综合监控工具（可同时查看 CPU、内存、磁盘、网络）。
```
dstat 1  # 每 1 秒刷新一次
```

4. 网络性能监控

网络性能问题通常表现为 带宽占满、延迟过高 或 连接数过多（如 TIME_WAIT 堆积）。

(1) 核心监控指标

带宽占用（Bandwidth）：入/出流量的速率（单位 Mbps）。
延迟（Latency）：数据包从发送到接收的时间（如 ping 延迟）。
连接数（Connections）：当前 TCP 连接数（ESTABLISHED、TIME_WAIT 等状态）。
丢包率（Packet Loss）：传输过程中丢失的数据包比例。

(2) 监控工具与示例

iftop：实时查看网络接口的流量（按流量排序）。
```
iftop -i eth0  # 监控 eth0 接口的流量
```
输出关键列：
- TX/RX：发送/接收速率（KB/s）。
- 2s/10s/40s：最近 2/10/40 秒的平均流量。
示例：发现 eth0 的 RX 速率为 100Mbps（接近千兆网卡上限），需检查是否有大流量应用。
nload：图形化显示各接口的实时带宽（需安装）。
```
nload eth0
```
ss：查看 TCP 连接状态（比 netstat 更高效）。
```
ss -ant | grep TIME_WAIT  # 查看 TIME_WAIT 状态的连接数
ss -s  # 统计总连接数、各状态连接数
```
示例：TIME_WAIT 连接数超过 10000，可能导致端口耗尽，需调整内核参数 net.ipv4.tcp_tw_reuse=1。
tcpdump：抓包分析网络流量（定位异常请求）。
```
tcpdump -i eth0 port 80 -n  # 抓取 eth0 接口 80 端口的流量
```

5. 进程性能监控

进程是系统的“执行单元”，性能问题通常表现为 高 CPU/内存占用、僵尸进程 或 异常重启。

(1) 核心监控指标

进程状态（State）：R（运行）、S（睡眠）、D（不可中断睡眠）、Z（僵尸）、T（停止）。
CPU/内存占用：进程占用的 CPU 和内存比例。
父进程 ID（PPID）：定位僵尸进程的父进程（避免孤儿进程堆积）。

(2) 监控工具与示例

ps：查看进程详细信息。
```
ps aux | sort -k3nr | head  # 按 CPU 占用降序排列前 10 进程
ps -ef | grep Z  # 查看僵尸进程
```
示例：发现 defunct 状态的僵尸进程，其父进程 PPID=1（init 进程），需终止父进程或手动清理。
pstree：以树状图显示进程父子关系。
```
pstree -p  # 显示进程 PID
```

pgrep/pkill：按名称查找或终止进程。

pgrep nginx  # 查找所有 nginx 进程的 PID
pkill -9 nginx  # 强制终止所有 nginx 进程

二、常见问题诊断与优化方法

通过监控工具定位到异常指标后，需针对性地优化。以下是常见问题场景及解决方案。

场景1：CPU 使用率持续过高（>80%）

诊断步骤：

用 top 或 htop 找到占用 CPU 最高的进程（如 mysql、java）。
用 pidstat -p <PID> 1 查看该进程的 CPU 细分（用户态 %usr 或内核态 %sys）。
若 %sys 高，可能是系统调用频繁（如频繁 open/close 文件）；若 %usr 高，可能是应用代码逻辑复杂或死循环。

优化方法：

调整进程优先级：用 renice 降低高 CPU 进程的优先级（nice 值越大，优先级越低）。
```
renice 10 -p <PID>  # 将 PID 进程的 nice 值设为 10（默认 0）
```
优化应用代码：检查是否有死循环、递归过深或低效算法（如用 perf 分析热点函数）。
```
perf top -p <PID>  # 实时查看进程的热点函数（CPU 消耗最多的函数）
```
限制 CPU 资源：用 cgroups 限制进程的 CPU 使用率（适合容器化场景）。

场景2：内存不足（可用内存 < 10%，频繁使用 Swap）

诊断步骤：

用 free -h 确认内存和 Swap 使用情况（Swap 列 used 接近 total）。
用 vmstat 1 观察 si（Swap In）和 so（Swap Out）是否持续 >0（说明物理内存不足）。
用 pmap -x <PID> 找到占用内存最大的进程（如 Java 应用的堆内存、数据库的缓存）。

优化方法：

释放缓存内存：手动清理内核缓存（需谨慎，可能影响 I/O 性能）。

sync  # 同步缓存到磁盘
echo 1 > /proc/sys/vm/drop_caches  # 释放页缓存（Page Cache）
echo 2 > /proc/sys/vm/drop_caches  # 释放目录项和 inode 缓存

调整进程内存限制：用 ulimit -v 限制进程的虚拟内存大小（需修改 /etc/security/limits.conf 持久化）。
修复内存泄漏：通过 pmap 或应用日志（如 Java 的 HeapDump）定位泄漏点，修复代码。
增加物理内存或调整 Swap：若长期不足，升级服务器内存或增大 Swap 分区（但 Swap 仅作为临时缓冲，不可替代物理内存）。

场景3：磁盘 I/O 延迟高（`await > 50ms`）

诊断步骤：

用 iostat -dx 1 确认 %util（接近 100%）、await（高）、svctm（正常）。
用 iotop 找到高 I/O 进程（如数据库的 mysqld、日志写入的 rsyslogd）。
检查文件系统类型（如 ext4、XFS）和挂载选项（如 noatime 是否启用）。

优化方法：

更换更快的存储设备：将机械盘（HDD）替换为 SSD（随机 I/O 性能提升 10 倍以上）。
优化文件系统：
- 启用 noatime 挂载选项（禁用访问时间更新，减少写操作）：
```
/dev/sda1 / xfs defaults,noatime 0 0  # 修改 /etc/fstab
mount -o remount /  # 重新挂载生效
```
- 调整文件系统块大小（如 XFS 的 blocksize=4k 适合数据库）。
减少 I/O 请求：
- 数据库优化：合并小文件、使用批量写入（如 MySQL 的 innodb_flush_log_at_trx_commit=2 减少日志写入次数）。
- 日志轮转：用 logrotate 定期切割大日志文件，避免单文件过大。

场景4：网络延迟高（`ping` 延迟 > 200ms）或丢包

诊断步骤：

用 ping <目标IP> 测试基础延迟和丢包率。
用 traceroute <目标IP> 定位网络跳点（哪一跳开始延迟或丢包）。
用 ss -ti 查看 TCP 连接的详细统计（如重传次数 retrans）。

优化方法：

调整内核网络参数：

增大 TCP 接收/发送缓冲区（减少网络延迟）：

net.core.rmem_max=16777216  # 接收缓冲区最大值（16MB）
net.core.wmem_max=16777216  # 发送缓冲区最大值（16MB）
net.ipv4.tcp_rmem="4096 87380 16777216"  # 接收缓冲区范围
net.ipv4.tcp_wmem="4096 87380 16777216"  # 发送缓冲区范围

减少 TIME_WAIT 连接数（避免端口耗尽）：

net.ipv4.tcp_tw_reuse=1  # 允许重用 TIME_WAIT 连接
net.ipv4.tcp_tw_recycle=1  # 加速回收 TIME_WAIT 连接（需谨慎，可能影响 NAT 环境）

优化应用层配置：
- 数据库：启用连接池（如 HikariCP），减少 TCP 握手开销。
- Web 服务器：启用 HTTP/2（多路复用），减少连接数。

场景5：僵尸进程（Zombie Process）堆积

诊断步骤：

用 ps aux | grep Z 查看僵尸进程（状态为 Z）。
用 pstree -p <PPID> 找到僵尸进程的父进程（PPID 列）。

优化方法：

终止父进程：僵尸进程的父进程若不再需要，可直接终止（子进程会被 init 进程接管并回收资源）。
```
kill -9 <PPID>  # 终止父进程
```
手动回收资源：若父进程无法终止（如系统关键进程），可重启服务器（临时方案）。

三、实战案例：综合性能优化

案例背景

某电商服务器近期响应缓慢，用户反馈“页面加载慢”，运维人员需快速定位问题并优化。

诊断过程

初步排查：用 top 发现 mysql 进程占用 CPU 70%，await（磁盘 I/O 等待时间）为 45ms（机械盘正常约 15ms）。
深入分析：
- iotop 显示 mysql 进程每秒写操作 500 次（IOPS 达到机械盘上限）。
- vmstat 显示 si=100、so=50（Swap 频繁交换，物理内存不足）。
- pmap 查看 mysql 进程内存，发现其堆内存占用 8GB（总内存 16GB，剩余可用仅 2GB）。
根因定位：
- MySQL 因查询未命中索引，导致大量全表扫描（I/O 密集）。
- 应用日志未分割，/var/log/app.log 增长至 100GB（频繁写磁盘）。

优化措施

MySQL 优化：
- 为高频查询字段添加索引（如 user_id、order_time）。
- 调整 my.cnf 配置，增大 innodb_buffer_pool_size（从 4GB 调至 8GB，减少磁盘 I/O）。
日志优化：
- 用 logrotate 配置日志切割（每日切割，保留 7 天），避免单文件过大。
- 将日志写入 tmpfs（内存文件系统），减少磁盘写操作：
```
tmpfs /var/log/app.log tmpfs size=2G,mode=1777 0 0  # 修改 /etc/fstab
```
内存扩容：将服务器内存从 16GB 升级至 32GB，避免 Swap 使用。
磁盘升级：将机械盘（HDD）替换为 SSD，提升随机 I/O 性能。