在linux上写IO中断？
我的应用程序使用 O_DIRECT 将 2MB 的数据直接刷新到 3 路条带存储（作为 lvm 卷安装）。
我在此存储上的写入速度非常慢。 iostat 显示较大的请求大小正在被分解为较小的请求。
avgrq-sz <20...该驱动器上的读取内容不多。
刷新 2MB 的连续内存块（使用 mlock 来确保这一点）、扇区对齐（使用 posix_memalign ）需要大约 2 秒，而使用 dd 进行测试 和 iozone 将存储能力评为 > 20Mbps的写入速度。
如果您能提供有关如何进一步调查此问题的任何线索，我将不胜感激。
PS：如果这不是此查询的正确论坛，我希望有一个可能有帮助的指标。
谢谢。
My application is using O_DIRECT for flushing 2MB worth of data directly to a 3-way-stripe storage (mounted as an lvm volume)..
I am getting a very pathetic write speed on this storage. The iostat shows that the large request size is being broken into smaller ones.
avgrq-sz is <20... There aren't much read on that drive.
It takes around 2 seconds to flush down 2MB worth of contiguous memory blocks (using mlock to assure that), sector aligned (using posix_memalign), whereas tests with dd and iozone rate the storage capable of > 20Mbps of write speed.
I would appreciate any clues on how to investigate this issue further.
PS: If this is not the right forum for this query, I would appreciate indicators to a one that could be helpful.
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
磁盘本身可能有最大请求大小，需要权衡块大小和延迟（发送到磁盘的请求越大，消耗的时间可能越长），并且可以有 驱动程序在单个请求中可以消耗多少矢量 I/O 的限制。考虑到上述所有情况，当进一步向堆栈提交时，内核将“分解”太大的单个请求。
不幸的是，如果没有看到实际提交 I/O 的代码（也许您的程序正在提交 10KBytes），很难说为什么
avgrq-sz如此小（如果它在每个 I/O 大约 10KBytes 的扇区中）缓冲区？）。我们也不知道在提问者测试期间iozone和dd是否使用O_DIRECT。如果不是，那么它们的 I/O 将进入写回缓存，然后稍后流出，内核可以以更优化的方式做到这一点。注意：使用
O_DIRECT并不是更快的条纹。在正确的情况下，O_DIRECT可以降低开销，但只编写O_DIRECT如果您想达到尽可能高的吞吐量，那么使用磁盘会增加您并行提交 I/O 的压力（例如通过 AIO/io_uring或通过多个进程/线程），因为您已经抢走了内核为您创建并行提交到设备的最佳方式。The disk itself may have a maximum request size, there is a tradeoff being block size and latency (the bigger the request being sent to the disk the longer it will likely take to to be consumed) and there can be constraints on how much vectored I/O a driver can consume in a single request. Given all the above, the kernel is going to "break up" single requests that are too large when submitting further down the stack.
Unfortunately it's hard to say why the
avgrq-szis so small (if its in sectors that about 10KBytes per I/O) without seeing the code actually submitting the I/O (maybe your program is submitting 10KByte buffers?). We also don't know ifiozoneandddwere usingO_DIRECTduring the questioners test. If they weren't then their I/O would have been going into the write back cache and then streamed out later and the kernel can do that in a more optimal fashion.Note: Using
O_DIRECTis NOT a go faster stripe. In the right circumstancesO_DIRECTcan lower overhead BUT writingO_DIRECTly to do disk increases the pressure on you to submit I/O in parallel (e.g. via AIO/io_uringor via multiple processes/threads) if you want to reach the highest possible throughput because you have robbed the kernel of its best way of creating parallel submission to the device for you.