I/O 子系统优化：从 ASM 到 Linux I/O 栈的全链路调优

发表于 更新于 分类于

在 Oracle 数据库的性能优化领域中，CPU 和内存的问题往往可以通过相对直观的方式定位和解决，而 I/O 子系统则是最为隐蔽、影响最为深远的性能瓶颈。作为 OCM 认证的 DBA，我在多年的生产环境实践中深刻体会到：绝大多数严重的数据库性能问题，最终都会归结到 I/O 层面。本文将从理论到实践，系统性地介绍 Oracle I/O 子系统的全链路优化方法。

一、问题背景

I/O 是数据库性能的最终瓶颈

无论数据库的 SQL 优化做得多么精妙，无论 SGA 配置得多么合理，最终所有的数据变更都需要持久化到存储设备上。当 I/O 子系统成为瓶颈时，整个数据库的性能表现将急剧下降。

在实际生产环境中，最常见的 I/O 相关等待事件包括：

  • db file sequential read：通常与索引访问相关，表示单块 I/O 读取，最常见的原因是索引范围扫描和通过 ROWID 访问表数据
  • db file scattered read：通常与全表扫描相关，表示多块 I/O 读取，对应 DB_FILE_MULTIBLOCK_READ_COUNT 参数
  • log file sync：LGWR 将 Redo Log Buffer 写入 Online Redo Log 的等待，直接影响事务提交延迟
  • db file parallel write：DBWR 将脏块写入数据文件的等待

存储性能问题的业务影响

当 I/O 子系统出现性能瓶颈时，业务层面通常表现为：

  1. 交易响应时间波动剧烈：正常情况下毫秒级响应的交易，偶尔飙升到秒级甚至更高
  2. 批量任务执行时间显著增长：ETL、报表等批处理任务运行时间翻倍甚至更长
  3. 系统整体吞吐量下降：并发用户数增加时，系统性能出现断崖式下降而非线性衰减

曾经遇到一个典型案例：某核心业务系统在业务高峰期频繁出现 “enq: TX - row lock contention”，看似是锁竞争问题，深入分析后发现根因是存储阵列缓存（Cache）命中率下降，导致 I/O 延迟从 1ms 飙升到 50ms 以上，LGWR 写入延迟增大，进而导致 log file sync 等待增加，事务持锁时间延长，最终表现为锁竞争。

二、理论分析

2.1 Oracle I/O 模型

异步 I/O 与同步 I/O

Oracle 数据库在 I/O 操作上支持两种模式：

  • 同步 I/O（Synchronous I/O）：进程发起 I/O 请求后阻塞等待，直到 I/O 完成后才继续执行。这种方式编程模型简单，但对高并发场景下会浪费大量 CPU 时间在等待 I/O 上
  • 异步 I/O（Asynchronous I/O）：进程发起 I/O 请求后立即返回，不等待 I/O 完成，通过回调或轮询机制获取 I/O 完成状态。这种方式允许进程在等待 I/O 完成的同时处理其他任务，显著提高 CPU 利用率

在 Oracle 中，异步 I/O 的启用由以下参数控制：

1
2
3
4
5
6
7
8
9
-- 查看当前异步 I/O 配置
SELECT name, value FROM v$parameter 
WHERE name IN ('disk_asynch_io', 'filesystemio_options');

-- filesystemio_options 参数值含义：
-- NONE          : 禁用 Direct I/O 和异步 I/O
-- ASYNCH        : 启用异步 I/O，使用 Buffered I/O
-- DIRECTIO      : 启用 Direct I/O，使用同步 I/O  
-- SETALL        : 同时启用 Direct I/O 和异步 I/O（推荐）

Direct I/O 与 Buffered I/O

  • Buffered I/O：数据先经过操作系统 Page Cache，再写入磁盘。优点是可以利用 OS 的缓存机制；缺点是数据经过两次拷贝（OS Cache → SGA），且存在数据一致性风险
  • Direct I/O：数据绕过操作系统 Page Cache，直接从用户空间写入磁盘设备。避免了双重缓存，减少了 CPU 开销和内存拷贝

对于 Oracle 数据库，强烈建议使用 Direct I/O。因为 Oracle 自身有完善的缓存管理机制（SGA/Buffer Cache），OS Page Cache 的存在不仅多余，还会导致内存浪费和额外的 CPU 开销。

DBWR 与 LGWR 的 I/O 模式

  • DBWR（Database Writer）：负责将 Buffer Cache 中的脏块（Dirty Blocks）写入数据文件。DBWR 支持异步 I/O 和批量写入（Write Batch），以提高写入效率。在高并发 OLTP 系统中，DBWR 的写入能力直接影响 Checkpoint 效率和 Buffer Cache 的可用空间
  • LGWR（Log Writer）：负责将 Redo Log Buffer 的内容写入 Online Redo Log 文件。LGWR 的 I/O 模式直接影响事务提交延迟（log file sync 等待时间）。LGWR 需要低延迟、高优先级的 I/O 路径

2.2 ASM 条带化

ASM Fine-grained vs Coarse-grained 条带

ASM（Automatic Storage Management）提供两种条带化粒度：

特性 Fine-grained Coarse-grained
条带大小 128KB 1 AU（通常 1MB/4MB）
适用场景 OLTP（小 I/O、随机读写） DSS/数据仓库（大 I/O、顺序读写）
条带宽度 跨所有磁盘 跨所有磁盘
I/O 分布 更均匀 相对集中

ASM AU 大小选择

ASM Allocation Unit（AU）大小的选择对性能有重要影响：

  • 1MB（默认）：适合大多数 OLTP 场景
  • 4MB：适合大型数据仓库，减少元数据开销
  • 8MB/16MB/32MB/64MB：超大规模数据库
1
2
3
4
5
6
7
8
9
-- 查看磁盘组的 AU 大小
SELECT name, allocation_unit_size/1024/1024 AS au_size_mb 
FROM v$asm_diskgroup;

-- 创建磁盘组时指定 AU 大小
CREATE DISKGROUP DATA 
  NORMAL REDUNDANCY
  DISK '/dev/sdb1', '/dev/sdc1'
  ATTRIBUTE 'au_size' = '4M';

Rebalance 机制与性能影响

当 ASM 磁盘组发生变更（添加/删除磁盘、磁盘故障）时，ASM 会自动执行 Rebalance 操作，重新分布数据以保持负载均衡。Rebalance 操作会消耗大量 I/O 资源，对在线业务产生影响。

1
2
3
4
5
6
7
8
-- 查看 Rebalance 操作进度
SELECT * FROM v$asm_operation;

-- 手动控制 Rebalance 速度（Power 值 0-11，0 表示暂停）
ALTER DISKGROUP DATA REBALANCE POWER 4;

-- 在低峰期执行 Rebalance
ALTER DISKGROUP DATA REBALANCE POWER 8 WAIT;

2.3 Linux I/O 栈

I/O Scheduler 选择

Linux 内核提供了多种 I/O 调度器，对数据库性能影响显著：

  • mq-deadline：多队列版本的 Deadline 调度器，为每个 I/O 请求设置截止时间，兼顾读写公平性和延迟保障。推荐用于大多数 Oracle 数据库场景
  • none（noop）：不进行任何调度，直接将 I/O 请求发送到设备。推荐用于 NVMe SSD 和 SAN 存储，因为这些设备自身已有完善的调度逻辑
  • kyber：基于目标延迟的调度器，适合快速设备
  • bfq：Budget Fair Queuing，适合桌面和交互式场景，不推荐用于数据库
1
2
3
4
5
6
7
8
9
# 查看当前 I/O Scheduler
cat /sys/block/sda/queue/scheduler

# 临时修改 I/O Scheduler
echo mq-deadline > /sys/block/sda/queue/scheduler

# 永久修改（通过 GRUB 参数）
# 编辑 /etc/default/grub，在 GRUB_CMDLINE_LINUX 中添加：
# elevator=mq-deadline

文件系统选择

文件系统 特点 适用场景
XFS 高性能、支持大文件、优秀的并发性能 推荐用于 Oracle 数据文件
EXT4 成熟稳定、广泛支持 通用场景
ASM Oracle 原生存储管理 生产环境首选

异步 I/O 配置

Linux 系统中，异步 I/O 的并发数由内核参数 fs.aio-max-nr 控制：

1
2
3
4
5
6
7
8
9
# 查看当前设置
sysctl fs.aio-max-nr

# 修改为更大值（推荐至少 1048576）
echo "fs.aio-max-nr = 1048576" >> /etc/sysctl.conf
sysctl -p

# 查看当前已使用的 AIO 请求数
cat /proc/sys/fs/aio-nr

2.4 存储多路径

在 SAN 存储环境中，主机到存储阵列之间通常存在多条物理路径。使用 Multipath（DM-Multipath）可以实现路径冗余和 I/O 负载均衡。

负载均衡策略

常用的负载均衡策略包括：

  • round-robin：轮询方式，将 I/O 均匀分配到所有路径
  • service-time：根据路径的服务时间动态分配 I/O，延迟低的路径获得更多 I/O
  • queue-length：根据路径上的队列长度分配 I/O
1
2
3
4
5
6
7
8
9
# /etc/multipath.conf 配置示例
defaults {
    polling_interval    30
    path_grouping_policy  multibus
    path_selector       "round-robin 0"
    failback            immediate
    no_path_retry       5
    rr_min_io           100
}

三、实战操作

3.1 I/O 性能诊断

iostat 与 iowait 综合诊断脚本

以下是一个生产环境中常用的 I/O 性能诊断脚本，综合了 iostat 和系统级 I/O 指标：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
#!/bin/bash
# io_diagnosis.sh - Oracle I/O 性能诊断脚本
# 用法: ./io_diagnosis.sh [采样间隔秒数] [采样次数]

INTERVAL=${1:-5}
COUNT=${2:-12}

echo "============================================"
echo "  Oracle I/O 子系统性能诊断报告"
echo "  采集时间: $(date '+%Y-%m-%d %H:%M:%S')"
echo "  采样间隔: ${INTERVAL}s, 采样次数: ${COUNT}"
echo "============================================"

# 1. CPU iowait 概览
echo ""
echo "--- CPU I/O Wait 概览 ---"
echo "us    sy    id    wa    st"
mpstat 1 ${COUNT} | grep -v "CPU\|^$" | tail -${COUNT} | \
  awk '{printf "%-6s%-6s%-6s%-6s%-6s\n", $3, $5, $12, $6, $7}'

# 2. 各磁盘 I/O 详细统计
echo ""
echo "--- 磁盘 I/O 详细统计 (iostat -xz) ---"
iostat -xz ${INTERVAL} ${COUNT} | grep -E "Device|sd[a-z]|nvme"

# 3. I/O 等待最高的进程
echo ""
echo "--- I/O 等待最高的 Top 10 进程 ---"
iotop -b -o -n ${COUNT} -d ${INTERVAL} 2>/dev/null | head -20 || \
  echo "(iotop 不可用，请安装: yum install iotop)"

# 4. Oracle I/O 等待事件
echo ""
echo "--- Oracle I/O 相关等待事件 (需要 sqlplus) ---"
echo "请在 SQL*Plus 中执行以下查询："
cat << 'SQL'
SELECT event, total_waits, time_waited_micro/1000000 AS time_waited_sec,
       ROUND(average_wait/1000, 2) AS avg_wait_ms
FROM v$system_event
WHERE event IN (
    'db file sequential read',
    'db file scattered read', 
    'log file sync',
    'db file parallel write',
    'log file parallel write',
    'direct path read',
    'direct path write'
)
ORDER BY time_waited_micro DESC;
SQL

使用 iostat 输出中的关键指标：

  • %util：磁盘繁忙百分比。持续超过 80% 表示磁盘已接近饱和
  • await：平均 I/O 等待时间（毫秒）。HDD 应低于 10ms，SSD 应低于 1ms
  • avgqu-sz：平均 I/O 队列长度。值越大说明 I/O 越繁忙
  • r/s, w/s：每秒读写次数（IOPS）
  • rkB/s, wkB/s：每秒读写吞吐量

数据库内部 I/O 监控

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
-- 查看各数据文件的 I/O 统计
SELECT f.file#,
       d.name AS file_name,
       f.phyrds  AS physical_reads,
       f.phywrts AS physical_writes,
       f.readtim AS read_time_cs,
       f.writetim AS write_time_cs,
       CASE WHEN f.phyrds > 0 
            THEN ROUND(f.readtim * 10 / f.phyrds, 2) 
            ELSE 0 END AS avg_read_ms,
       CASE WHEN f.phywrts > 0 
            THEN ROUND(f.writetim * 10 / f.phywrts, 2) 
            ELSE 0 END AS avg_write_ms
FROM v$filestat f, v$datafile d
WHERE f.file# = d.file#
ORDER BY f.phyrds + f.phywrts DESC
FETCH FIRST 20 ROWS ONLY;

-- 详细的 I/O 按文件类型统计（12c+）
SELECT filetype_name,
       SUM(small_read_megabytes) AS small_read_mb,
       SUM(large_read_megabytes) AS large_read_mb,
       SUM(small_write_megabytes) AS small_write_mb,
       SUM(large_write_megabytes) AS large_write_mb,
       ROUND(AVG(small_sync_read_latency), 2) AS avg_sync_read_ms
FROM v$iostat_file
GROUP BY filetype_name
ORDER BY small_read_mb + large_read_mb DESC;

AWR 报告 I/O 章节解读

AWR 报告中 I/O 相关的关键部分：

  1. Tablespace I/O Statistics：各表空间的 I/O 吞吐量和延迟，识别热点表空间
  2. File I/O Statistics：各数据文件的 I/O 分布，检查是否存在 I/O 热点文件
  3. Buffer Pool Statistics：Buffer Cache 命中率，过低说明频繁物理读
  4. Instance Activity Stats：关注 physical reads、physical writes、redo size 等指标

3.2 ASM 优化

ASM 磁盘组管理与 Rebalance

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
-- 查看所有磁盘组状态
SELECT name, state, type, total_mb, free_mb,
       ROUND(free_mb/total_mb*100, 2) AS free_pct
FROM v$asm_diskgroup;

-- 查看磁盘组中各磁盘的 I/O 分布
SELECT dg.name AS diskgroup,
       d.path,
       d.reads,
       d.writes,
       d.read_errs,
       d.write_errs,
       d.read_time,
       d.write_time,
       d.bytes_read/1024/1024 AS read_mb,
       d.bytes_written/1024/1024 AS write_mb
FROM v$asm_disk d, v$asm_diskgroup dg
WHERE d.group_number = dg.group_number
ORDER BY dg.name, d.reads + d.writes DESC;

-- 检查磁盘组 Rebalance 操作
SELECT group_number, operation, state, power, est_minutes
FROM v$asm_operation;

-- 调整 Rebalance Power（0=暂停, 1-11=速度递增）
-- 生产环境建议使用较低的 Power 值（2-4）以减少业务影响
ALTER DISKGROUP DATA REBALANCE POWER 2;

-- 添加新磁盘到磁盘组
ALTER DISKGROUP DATA ADD DISK '/dev/sdd1' NAME DATA_0004;

-- 查看 ASM 模板
SELECT dg.name AS diskgroup, t.name AS template, 
       t.redundancy, t.stripe
FROM v$asm_template t, v$asm_diskgroup dg
WHERE t.group_number = dg.group_number
ORDER BY dg.name, t.name;

ASM 磁盘性能监控

建议定期监控 ASM 磁盘的 I/O 分布均匀性。如果发现某些磁盘的读写量显著高于其他磁盘（偏差超过 20%），可能需要执行 Rebalance 或重新规划磁盘布局。

3.3 Linux I/O 调优

I/O Scheduler 配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
# 针对 NVMe SSD 使用 none 调度器
for dev in /sys/block/nvme*; do
    echo none > ${dev}/queue/scheduler
    echo "Set ${dev} to none scheduler"
done

# 针对 SAS/SATA HDD 使用 mq-deadline 调度器
for dev in /sys/block/sd*; do
    echo mq-deadline > ${dev}/queue/scheduler
    echo "Set ${dev} to mq-deadline scheduler"
done

# 调整 mq-deadline 调度器参数
# 读请求截止时间（毫秒）
echo 500 > /sys/block/sda/queue/iosched/read_expire
# 写请求截止时间（毫秒） 
echo 5000 > /sys/block/sda/queue/iosched/write_expire
# 写批次大小
echo 16 > /sys/block/sda/queue/iosched/writes_starved

文件系统挂载选项

对于 Oracle 数据文件使用的 XFS 文件系统，推荐以下挂载选项：

1
2
3
4
5
6
7
8
9
# /etc/fstab 中的 XFS 推荐挂载选项
/dev/mapper/data_lv  /oradata  xfs  rw,noatime,nodiratime,logbufs=8,logbsize=256k,allocsize=64m  0 0

# 选项说明：
# noatime     - 不更新文件访问时间戳，减少元数据写入
# nodiratime  - 不更新目录访问时间戳
# logbufs=8   - 增加日志缓冲区数量
# logbsize=256k - 增加日志缓冲区大小
# allocsize=64m - 预分配大小，优化大文件写入

异步 I/O 系统参数配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# /etc/sysctl.conf 中的 I/O 相关参数

# 异步 I/O 最大请求数
fs.aio-max-nr = 1048576

# 虚拟内存相关优化
vm.dirty_ratio = 5
vm.dirty_background_ratio = 2
vm.dirty_expire_centisecs = 300
vm.dirty_writeback_centisecs = 100

# 应用配置
sysctl -p

# 验证 Oracle 使用了异步 I/O
# 查看 Oracle 进程的 I/O 方式
strace -e io_submit,io_getevents -p <oracle_pid> -c

3.4 Oracle I/O 参数

关键 I/O 参数配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
-- FILESYSTEMIO_OPTIONS: 控制文件系统的 I/O 方式
-- 推荐设置为 SETALL（同时启用 Direct I/O 和异步 I/O）
ALTER SYSTEM SET FILESYSTEMIO_OPTIONS='SETALL' SCOPE=SPFILE;

-- DISK_ASYNCH_IO: 启用磁盘异步 I/O
-- 使用 ASM 时默认为 TRUE
ALTER SYSTEM SET DISK_ASYNCH_IO=TRUE SCOPE=SPFILE;

-- DB_FILE_MULTIBLOCK_READ_COUNT: 多块读的块数
-- 影响全表扫描性能，一般设置为 16 或 32
-- 12c 以后可以设置为 0，由 Oracle 自动调优
ALTER SYSTEM SET DB_FILE_MULTIBLOCK_READ_COUNT=16 SCOPE=BOTH;

-- DB_WRITER_PROCESSES: DBWR 进程数量
-- 默认为 CPU_COUNT/8，高 I/O 负载环境可适当增加
ALTER SYSTEM SET DB_WRITER_PROCESSES=4 SCOPE=SPFILE;

-- 相关隐含参数（仅在特殊场景下使用，需 Oracle Support 确认）
-- _db_file_direct_io_count: Direct I/O 的大小
-- _lgwr_io_slaves: LGWR I/O 从进程数量

-- 验证参数生效
SHOW PARAMETER FILESYSTEMIO_OPTIONS;
SHOW PARAMETER DISK_ASYNCH_IO;
SHOW PARAMETER DB_FILE_MULTIBLOCK_READ_COUNT;

四、结果验证

I/O 延迟指标对比

优化前后的典型 I/O 延迟对比：

指标 优化前 优化后 改善幅度
db file sequential read 平均等待 8.5ms 1.2ms 86%
db file scattered read 平均等待 12.3ms 2.1ms 83%
log file sync 平均等待 5.6ms 0.8ms 86%
iostat await (数据盘) 15ms 2ms 87%
Buffer Cache Hit Ratio 92% 99.5% -

AWR 报告 I/O 指标验证

优化完成后，通过 AWR 报告验证以下关键指标：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
-- 对比优化前后的 AWR 快照
-- 获取 I/O 相关的统计信息变化
SELECT sn.snap_id,
       sn.begin_interval_time,
       st.stat_name,
       st.value
FROM dba_hist_sysstat st, dba_hist_snapshot sn
WHERE st.snap_id = sn.snap_id
  AND st.stat_name IN (
      'physical read total bytes',
      'physical write total bytes',
      'physical read total IO requests',
      'physical write total IO requests',
      'redo size'
  )
  AND sn.begin_interval_time > SYSDATE - 1
ORDER BY sn.snap_id, st.stat_name;

重点关注：

  1. I/O 延迟下降：db file sequential read 的平均等待时间应降至 2ms 以下（SSD）或 8ms 以下（HDD）
  2. I/O 吞吐量提升：同等业务负载下的 IOPS 和吞吐量应有明显提升
  3. iowait 降低：CPU 的 iowait 百分比应降至 5% 以下
  4. log file sync 改善：平均等待时间应降至 2ms 以下

性能测试结果

使用 fio 进行存储基准测试，验证优化效果：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 随机读测试（模拟 OLTP 索引访问）
fio --name=rand_read --ioengine=libaio --direct=1 --bs=8k \
    --size=10G --numjobs=8 --iodepth=32 --rw=randread \
    --group_reporting --runtime=300

# 随机读写混合测试（模拟 OLTP 混合负载）
fio --name=rand_rw --ioengine=libaio --direct=1 --bs=8k \
    --size=10G --numjobs=8 --iodepth=32 --rw=randrw --rwmixread=70 \
    --group_reporting --runtime=300

# 顺序读测试（模拟全表扫描）
fio --name=seq_read --ioengine=libaio --direct=1 --bs=1M \
    --size=50G --numjobs=4 --iodepth=16 --rw=read \
    --group_reporting --runtime=300

五、经验总结

I/O 优化的优先级

根据我的实战经验，I/O 优化应遵循以下优先级：

  1. 存储硬件层（最重要）：选择合适的存储介质（NVMe SSD > SAS SSD > SAS HDD），这是优化的基石，软件层面的优化无法弥补硬件的不足
  2. 存储配置层：Multipath 配置、SAN Zoning、LUN 分配策略
  3. 操作系统层：I/O Scheduler、文件系统挂载选项、异步 I/O 参数
  4. ASM/存储管理层：ASM 磁盘组条带化、Rebalance 策略
  5. Oracle 数据库层：FILESYSTEMIO_OPTIONS、DB_FILE_MULTIBLOCK_READ_COUNT 等参数

存储选型建议

场景 推荐存储类型 推荐 I/O Scheduler
OLTP 核心系统 NVMe SSD none
OLTP 一般系统 SAS SSD none
数据仓库 SAS SSD + HDD 混合 mq-deadline (HDD), none (SSD)
归档/备份 HDD mq-deadline

常见 I/O 问题快速定位

遇到 I/O 相关性能问题时，可以按照以下流程快速定位：

  1. 第一步：检查 iostat 的 %util 和 await，确认是否存在磁盘饱和
  2. 第二步：检查 AWR 报告中的 Top Wait Events，确认 I/O 等待事件的排名和占比
  3. 第三步：检查 V$FILESTAT / V$IOSTAT_FILE，定位热点数据文件
  4. 第四步：检查操作系统层面的 I/O Scheduler 和文件系统挂载选项
  5. 第五步：检查 Multipath 路径状态和负载分布

关键经验：在处理 I/O 性能问题时，务必从操作系统层面开始排查，而不是直接调整数据库参数。很多时候，一个简单的 I/O Scheduler 变更或挂载选项调整就能带来显著的性能改善。

I/O 子系统优化是一项系统工程，需要 DBA 具备从存储硬件到数据库参数的全栈知识。希望本文的内容能够帮助大家在实际工作中更高效地定位和解决 I/O 相关的性能问题。