io_submit 等待所有 oracle dbwriter I/O答案

【问题标题】：io_submit waits for all oracle dbwriter I/Osio_submit 等待所有 oracle dbwriter I/O
【发布时间】：2015-10-21 18:31:52
【问题描述】：

作为背景，自 80 年代以来，我一直在调整数据库平台。所以，我过去处理过很多异步 I/O 问题。这个是新的，而且很奇怪。

首先，我在 RHEL 7.1 64 位 (3.10.0-229) 上使用带有 ASM 的 Oracle 12c。我一直在使用两个 EMC CX4-960 阵列，总共 72 个 SSD。我总共进行了约 105K 读取/秒，65K 写入/秒。（是的，这是一个非常强大的存储后端！）磁盘写入延迟为 2-3 毫秒。当 oracle dbwriters 刷新缓冲区（通常是大批量和异步）时，以下 strace 片段显示 io_submit() 和 io_getevents() 在几毫秒内完成，然后需要几毫秒才能完成所有写入，然后我们移动到下一批。（我在 io_submit() 行中去掉了提交块的详细信息：

294692 12:46:10.173955 io_submit(140662136606720, 301, ) = 301 <0.002482>
294692 12:46:10.178452 io_getevents(140662136606720, 38, 128, , {600, 0}) = 60 <0.000026>
294692 12:46:10.178766 times(NULL)      = 439014359 <0.000016>
294692 12:46:10.178845 io_getevents(140662136606720, 128, 128, , {0, 0}) = 85 <0.000109>
294692 12:46:10.179352 io_getevents(140662136606720, 128, 128, , {0, 0}) = 62 <0.000118>
294692 12:46:10.180207 io_getevents(140662136606720, 94, 128, , {0, 0}) = 76 <0.000115>
294692 12:46:10.180743 io_getevents(140662136606720, 18, 128, , {0, 0}) = 16 <0.000122>
294692 12:46:10.181994 io_getevents(140662136606720, 2, 128, , {0, 0}) = 2 <0.000032>
294692 12:46:10.182393 times(NULL)      = 439014359 <0.000016>
294692 12:46:10.182462 semtimedop(4718593, , 1, {3, 0}) = -1 EAGAIN (Resource temporarily unavailable) <2.999632>
294692 12:46:13.182193 times(NULL)      = 439014659 <0.000015>
294692 12:46:13.188183 io_submit(140662136606720, 319, ) = 319 <0.002741>
294692 12:46:13.193078 io_getevents(140662136606720, 40, 128, , {600, 0}) = 128 <0.000021>
294692 12:46:13.193583 times(NULL)      = 439014660 <0.000018>
294692 12:46:13.193663 io_getevents(140662136606720, 128, 128, , {0, 0}) = 119 <0.000116>
294692 12:46:13.194364 io_getevents(140662136606720, 72, 128, , {0, 0}) = 59 <0.000123>
294692 12:46:13.195876 io_getevents(140662136606720, 13, 128, , {0, 0}) = 13 <0.000021>
294692 12:46:13.196650 times(NULL)      = 439014661 <0.000017>
294692 12:46:13.196725 semtimedop(4718593, , 1, {2, 990000000}) = -1 EAGAIN (Resource temporarily unavailable) <2.989363>
294692 12:46:16.186196 times(NULL)      = 439014960 <0.000015>
294692 12:46:16.194006 io_submit(140662136606720, 276, ) = 276 <0.002434>
294692 12:46:16.198285 io_getevents(140662136606720, 36, 128, , {600, 0}) = 42 <0.000017>
294692 12:46:16.198518 times(NULL)      = 439014961 <0.000014>
294692 12:46:16.198572 io_getevents(140662136606720, 128, 128, , {0, 0}) = 48 <0.000092>
294692 12:46:16.198893 io_getevents(140662136606720, 128, 128, , {0, 0}) = 37 <0.000070>

到目前为止，一切都很好。然后我切换到我正在测试的两个 Tegile t3600 阵列。这些家伙甚至更快，并且可以以更低的延迟为我提供更多的 IOPS。问题是我很快遇到了 50% 或更高的 Oracle“空闲缓冲区等待”。 dbwriters 无法跟上，迫使前台写入和各种坏事。令人惊讶的是，dbwriter 无法使用如此快速的存储刷新足够的缓冲区。但 strace 显示了原因。请注意，iostat 显示平均磁盘写入延迟约为 0.7 毫秒。

19131 18:35:06.903628 io_submit(140538814074880, 517, ) = 517 <0.505505>
19131 18:35:07.414281 io_getevents(140538814074880, 40, 128, , {600, 0}) = 128 <0.000014>
19131 18:35:07.415091 io_getevents(140538814074880, 128, 128, , {0, 0}) = 128 <0.000012>
19131 18:35:07.416139 io_getevents(140538814074880, 128, 128, , {0, 0}) = 128 <0.000010>
19131 18:35:07.417134 semctl(753668, 33, SETVAL, 0x1) = 0 <0.000017>
19131 18:35:07.417553 semctl(688130, 103, SETVAL, 0x1) = 0 <0.000014>
19131 18:35:07.417640 semctl(655361, 130, SETVAL, 0x1) = 0 <0.000013>
19131 18:35:07.419923 io_submit(140538814074880, 248, ) = 248 <0.250174>
19131 18:35:07.673864 io_getevents(140538814074880, 22, 128, , {600, 0}) = 128 <0.000019>
19131 18:35:07.674735 io_getevents(140538814074880, 128, 128, , {0, 0}) = 128 <0.000010>
19131 18:35:07.676021 io_getevents(140538814074880, 128, 128, , {0, 0}) = 128 <0.000020>
19131 18:35:07.676660 semctl(753668, 5, SETVAL, 0x1) = 0 <0.000021>
19131 18:35:07.680954 io_submit(140538814074880, 507, ) = 507 <0.503491>
19131 18:35:08.190096 io_getevents(140538814074880, 38, 128, , {600, 0}) = 128 <0.000010>
19131 18:35:08.190617 io_getevents(140538814074880, 128, 128, , {0, 0}) = 128 <0.000008>
19131 18:35:08.193571 io_getevents(140538814074880, 128, 128, , {0, 0}) = 128 <0.000025>
19131 18:35:08.196128 semctl(720899, 38, SETVAL, 0x1) = 0 <0.000026>

因此，出于某种原因，包含 517 个块的 io_submit() 需要 505 毫秒才能返回。为什么？

任何想法为什么会发生这种情况？似乎该数组以某种方式告诉操作系统以串行方式发出写入。 FWIW，我什至在阵列控制器中启用了写回写缓存。所以它似乎是操作系统本身的东西

【问题讨论】：

有趣的问题，但超出了我的经验。我不确定，但也许更适合 dba.stackexchange.com ？祝你好运。
可能离题：我记得在 AIX 上有一个可调参数队列深度。是否有可能提交的请求多于硬件支持的数量？
恐怕你的问题太特殊了，下一步就是将printk添加到内核驱动源中。
@ibre541：在这两种情况下，队列深度 (/sys/block/sd*/queue/nr_requests) 都设置为 256。
你是直接读/写到块设备吗？否则我会怀疑文件系统在阻塞调用中执行了一些操作。比如元数据操作。

标签： arrays linux oracle aio

【解决方案1】：

问题在于，当 Linux 扫描 LUN 时，LUN 会在“启用写入缓存”的情况下宣传自己。这告诉 Linux 它必须使用强制单元访问来避免在缓存断电的情况下数据丢失，因为 Oracle 使用 O_SYNC（或 O_DSYNC？）打开 LUN。这是基于许多假设——缓存在 RAM 中、易失性等——但让我们接受这一点。 FUA 在性能方面是个坏消息。它还破坏了异步 I/O 的并行发布。

事实证明，该阵列有一个设置，告诉它是否向 Linux 服务器通告回写缓存。它不会改变数组的操作方式；它只是改变了它对主机的显示方式。通过将阵列上的 WBC 设置更改为 Disabled，Linux 主机在扫描 LUN 时会打印“Write cache disabled”行，现在异步写入行为正常。

【讨论】：