3. 数据库主机资源画像
数据库主机的性能问题很少是单一时刻的“突发故障”，更多是长期资源分配失衡的累积结果。要判断一台运行 Oracle、MySQL 或 PostgreSQL 的主机是否健康，不能只看某一刻 CPU 使用率是否飙高，而需要建立一套可对比、可回溯的性能基线。所谓基线，就是在业务正常、负载稳定的时段，采集 CPU、内存、磁盘 I/O、上下文切换、进程级资源占用等指标，形成一组“正常态参考值”。此后任何异常波动，都可以与基线对照，快速定位是数据库内部问题，还是主机资源被其他进程挤占。
本节围绕五类工具展开：top 用于快速观察整体负载与进程排名，vmstat 用于观察 CPU、内存、交换和上下文切换的宏观趋势，iostat 用于定位磁盘吞吐与延迟瓶颈，sar 用于历史数据回溯与长期趋势分析，pidstat 用于把资源消耗精确落到具体进程。它们不是互相替代的关系，而是从“面”到“点”逐层收敛的观测链。
上图展示了从工具采集到基线档案形成的完整观测链。下面逐一说明每个工具在数据库主机场景下的关键读数和判断方法。
top：第一眼定位整体负载与进程排名
top 是最快的入口。在数据库主机上，重点关注第一行负载均值与第三行 CPU 分布。例如一台 16 核主机，load average: 4.2, 3.8, 3.5 表示过去 1、5、15 分钟的平均可运行进程数约为 4，相对于 16 核并不算高；但如果 load average 持续超过核数，说明 CPU 排队明显。第三行中 %wa 是数据库主机最值得警惕的指标：若 wa 长期高于 10%，说明磁盘 I/O 已成为瓶颈，CPU 在等待 I/O 完成。此时按 P 按 CPU 排序、按 M 按内存排序，可以快速看到是数据库进程本身还是备份、日志、监控代理等外部进程在消耗资源。
vmstat：观察 CPU、内存与交换的宏观趋势
vmstat 5 12 表示每 5 秒采样一次，共 12 次，覆盖 1 分钟。关键列包括：r 运行队列长度，持续大于 CPU 核数说明 CPU 竞争激烈；si 和 so 是换入换出，数据库主机上理想值应接近 0，一旦持续非零，说明物理内存不足，数据库缓存被换出，性能会急剧下降；cs 上下文切换次数，若异常偏高，往往与大量短连接或锁竞争有关；us、sy、id、wa 则给出 CPU 时间分配。基线采集时，应记录平稳期的 r、cs、si/so 典型值，作为后续对比依据。
iostat：定位磁盘吞吐、延迟与饱和度
iostat -x 5 输出扩展统计，数据库主机重点看 r/s、w/s、await、%util。以一块 SSD 为例，若基线期 await 约 1~3 ms、%util 约 30%，而某时段 await 升至 25 ms、%util 接近 100%，说明设备已饱和，数据库的 redo 写入或全表扫描正在排队。需要注意，%util 对多队列 NVMe 设备并不完全线性，应结合 await 和队列深度综合判断。基线应记录数据盘、日志盘、归档盘各自的正常区间，因为不同盘承担不同 I/O 模式。
sar：历史回溯与长期趋势
sar 依赖 sysstat 服务持续采集，默认每 10 分钟写入一次历史文件。它的价值在于“事后复盘”：当业务反馈昨天 14:00 数据库变慢，可以用 sar -u -f /var/log/sa/sa15 -s 14:00:00 -e 15:00:00 回看当时的 CPU 分布，用 sar -d 回看磁盘，用 sar -r 回看内存。基线建立时，应至少保留一个完整业务周期的 sar 数据，并标注业务高峰、批处理窗口、备份窗口等时间点，使后续对比有明确参照。
pidstat：把资源消耗落到具体进程
当 top 或 vmstat 发现异常后，用 pidstat 精确定位。例如 pidstat -p <PID> 5 观察某数据库进程的 CPU 使用，pidstat -d 5 观察各进程磁盘读写，pidstat -r 5 观察内存占用。数据库主机上常见的情况是：mysqld 或 ora_pmon 等进程 CPU 正常，但一个备份脚本或日志采集 agent 占用了大量 I/O，导致数据库 await 升高。pidstat 能把“主机慢”转化为“哪个进程在消耗什么资源”，这是基线排查链的最后一环。
vmstat 5 60 >> /var/log/baseline/vmstat_$(date +%F).log，并同步记录 iostat -x 5 60 与 pidstat -d 5 60。基线不是一次性的，而应随业务增长定期更新。基线档案示例
下表给出一台 16 核、64 GB 内存、SSD 数据盘的 MySQL 主机在平稳期的基线参考区间（示例数据，用于说明字段与判断方式，非实测结果）：
| 指标 | 采集工具 | 基线参考区间 | 异常提示 |
|---|---|---|---|
| CPU us | top / vmstat | 40%~55% | 持续 > 75% 需排查慢查询 |
| CPU wa | top / vmstat | < 5% | 持续 > 10% 说明 I/O 瓶颈 |
| 运行队列 r | vmstat | < 4 | 持续 > 16 说明 CPU 排队 |
| 交换 si/so | vmstat | ≈ 0 | 持续非零说明内存不足 |
| 磁盘 await | iostat -x | < 10 ms | > 20 ms 需关注 |
| 磁盘 %util | iostat -x | < 60% | > 85% 接近饱和 |
| 数据库进程 CPU | pidstat | 30%~50% | 突增需结合慢日志 |
| 数据库进程 IO | pidstat -d | 依业务而定 | 备份/日志进程异常占用需隔离 |
需要强调的是，基线值因硬件、数据库类型、业务模型差异很大，上表仅用于说明“字段如何组织、判断如何表达”。真正可用的基线必须来自本机在平稳期的实际采集。建立基线后，日常巡检只需将当前值与基线区间对比：若 CPU us 正常但 wa 升高，优先查 iostat 和 pidstat -d；若 si/so 非零，优先查内存与数据库缓存配置；若 load 高但 CPU 空闲，则考虑 I/O 等待或锁竞争。通过这套从宏观到进程的观测链，数据库主机的资源画像才能从“感觉慢”变成“有据可查、有径可循”。