1. 学习目标

数据库运维遇到业务连不上数据库、SQL 卡住等问题时，不能只盯数据库本身。数据库最终运行在 Linux 上，CPU、内存、磁盘、文件系统、RAID 卡、存储阵列等任何一层异常，都可能表现为数据库响应慢甚至无法连接。
在某项目工作中遇到连接不上数据库的问题，经过排查和学习后，本笔记梳理一个遇到此类问题的实际排查思路：数据库服务器更换 RAID 卡后，业务系统间歇性无法连接数据库，随后连 SYSDBA 也失败。排查过程中进一步发现普通文件写入也异常、磁盘写等待高，因此将问题从“数据库故障”定位到“存储 I/O 性能异常”。

2. Linux 性能排查的整体思路

性能问题排查最重要的是先判断瓶颈出现在哪一层，排查通过按下面的顺序逐层缩小范围

业务报错 / 数据库连接失败
↓

数据库是否存活？服务/进程是否存在？
↓
本机能否直接连接数据库？
↓
Linux 是否整体卡顿？CPU / 内存 / IO 谁异常？
↓
如果 IO 异常：文件系统写入是否也慢？
↓
iostat 看延迟、队列、繁忙度
↓
iotop 定位哪个进程在大量读写
↓
dmesg / journalctl 看磁盘、RAID、SCSI、超时错误
↓
必要时交给系统/存储工程师检查 RAID 卡、磁盘、SAN/存储阵列

3. CPU 瓶颈分析

CPU 排查先看系统负载，再找到高 CPU 进程和线程。

# 查看负载
uptime

# 找 CPU 最高的进程
top -bn1 -o %CPU | head -15

# 找到某进程中 CPU 最高的线程
top -H -p <PID>

4. 内存瓶颈分析

内存排查重点看可用内存、Swap、运行队列以及是否发生 OOM。

# 查看内存/运行队列状态
vmstat -t 3 5

# 查看 OOM 日志
dmesg -T | grep -i "oom\|killed process"
journalctl -k | grep -i oom

# 查看页缓存
cat /proc/meminfo | grep -E "Cached|Buffers"

5. 磁盘 I/O 瓶颈分析

数据文件、日志文件、临时文件以及操作系统文件都依赖底层块设备。当 RAID 卡、磁盘、存储阵列或路径异常时，最常见的表现是 I/O 延迟和队列堆积。

# 推荐持续观察
iostat -xm 2

# 或采样 5 次，每 3 秒一次
iostat -xz 3 5

# 查看是什么进程在写
iotop -oPa

5.1 iostat 最重要的指标

5.2 延迟阈值怎么理解

参考问题中的经验值：HDD 的 await 超过约 20 ms 需要关注，SSD 超过约 5 ms 需要关注；现场项目中也可能把约 18 ms 作为存储延迟的经验关注线。
这些数字不是 Linux 的统一硬阈值。不同存储介质、RAID 级别、SAN/NVMe、虚拟化和业务负载差异很大。最可靠的方法是建立本机正常时期的基线，再看故障期是否明显偏离。

6. iostat 分析

截图第一组输出中部分设备的 r_await、w_await 数值很高，但后续 2 秒采样中多数设备又回到接近 0 的状态。
iostat 默认第一组数据通常是“自系统启动以来的累计平均”，后续才是每个采样周期的数据。排查实时问题时不能只看第一组；可以使用 iostat -y -xm 2 跳过第一份累计统计。

iostat -y -xm 2

6.1 图解

CPU 的 %iowait 在后续采样接近 0，说明截图时业务已经较为空闲。
后续采样中设备 aqu-sz 接近 0，说明实时 I/O 队列没有持续堆积。
后续 %util 很低，说明当前时刻设备并不忙。
第一组出现很高的 await，更像历史累计值，需要结合故障发生时的连续采样判断。

6.2 %util 超过 100% 怎么看

标准单设备统计中，%util 通常按设备处理 I/O 的忙碌时间比例理解。现场如果看到 300%、500% 这类数值，应先确认该项是否来自 RAID、device-mapper、multipath、虚拟块设备或工具版本差异。

# 查看逻辑盘、LVM、物理盘之间的层级
lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINT
lsblk -o NAME,KNAME,PKNAME,TYPE,SIZE,MOUNTPOINT

说明：%util 需要和 await、aqu-sz、吞吐、IOPS 一起看。对于 RAID 和多队列设备，即使接近 100%，也不能仅凭一个指标就断言存储已完全饱和。

7. 故障案例：更换 RAID 卡后数据库间歇性无法连接

案例现象：数据库服务器前段时间发生硬件问题并更换 RAID 卡。随后业务系统多次出现连接不上数据库，后来工程师反馈 SYSDBA 也无法连接。此时首先要区分“数据库自身异常”还是“底层操作系统/存储异常”。

7.1 第一步：确认数据库是否宕机

systemctl status DmServiceDMSERVER
ps -ef | grep dmserver

# 如果使用自定义服务名
systemctl status <DM服务名>

如果数据库进程不存在，继续看数据库日志和系统日志判断为何退出；如果进程仍然存在，则继续做本机连接测试。

7.2 第二步：自己从数据库服务器本机直连

su - dmdba
disql SYSDBA/<口令>@127.0.0.1:<端口>
如果远程业务连不上但本机 SYSDBA 能正常连接，更偏向网络、监听、连接数或应用侧问题；如果本机 SYSDBA 也长时间卡住或失败，就需要继续看 Linux 和存储。

7.3 第三步：看 Linux 是否已经被 I/O 拖慢

uptime
top
vmstat -t 3 5
iostat -y -xm 2

重点看：top 的 wa、vmstat 的 b/wa、iostat 的 r_await、w_await、aqu-sz、%util。如果 CPU 本身很空闲，但大量时间在等待磁盘，说明问题更偏向 I/O。

7.4 第四步：测试普通文件写入

cd /tmp
touch io_test_file
echo "$(date)" >> io_test_file
vi io_test_file

说明：测试应选择允许写入的临时目录，不要在数据库数据文件目录随意创建或修改文件。
案例中发现外部普通文件编辑也失败，同时数据库登录失败、写延迟过高，这些现象共同指向底层存储/RAID 性能问题，因此应让客户系统或存储工程师重点排查 RAID 卡、磁盘、存储路径和阵列状态。

7.5 第五步：判断是不是某个进程把磁盘打满

iotop -oPa
如果数据库进程、备份进程、日志归档进程或其他程序突然占满 I/O，就需要继续判断这是正常业务压力还是异常任务。

7.6 第六步：看内核是否报告磁盘、RAID 或超时错误

dmesg -T | egrep -i "I/O error|blk|reset|timeout|scsi|raid|nvme|buffer I/O"
journalctl -k | egrep -i "I/O error|blk|reset|timeout|scsi|raid|nvme|buffer I/O"

说明：如果服务器刚更换 RAID 卡，内核日志、RAID 管理工具以及硬件告警信息尤其重要。数据库层只能看到“写很慢/写失败”，真正根因可能在 RAID 控制器、电池/缓存策略、物理盘、链路或阵列侧。

7.7 最终定位思路

数据库连接失败
↓
数据库进程还在？
├─ 否 → 看数据库日志/系统日志，判断为何宕机
└─ 是
↓
本机 SYSDBA 能否连接？
├─ 能 → 查网络、监听、连接数、应用侧
└─ 不能 / 卡住
↓
top/vmstat 是否出现 IO 等待？
↓
iostat 是否出现高 await / 队列堆积 / 高繁忙度？
↓
普通文件 touch/vi 写入是否也异常？
├─ 否 → 继续查数据库自身锁、日志、事务、连接资源
└─ 是 → 基本可以把问题提升到 Linux/存储层
↓
RAID / 磁盘 / SAN / 存储阵列排查

Linux 性能瓶颈分析与故障排查