关于 Direct I/O

[IwfWcf]

今天做测试时发现一个很奇怪的现象，不知道有没有同学能解释一下

在不使用 Direct I/O 的情况下进行 AOF，pwrite 会比 write 慢很多。而使用 Direct I/O 的情况下 write 和 pwrite 的速度基本一样，而且 pwrite 的耗时要比不使用 Direct I/O 时要小很多。

[styx]

如果你是用 pwrite 和 write 都做 append 操作的话，我感觉 pwrite 做的操作也许会比 write 多一点，但是我就不太理解为什么用 pwrite 去 append。

如果你用 O_DIRECT 绕过 buffer cache 的话，而且都是 append 操作的话，我觉得速度一样挺合理的，因为都是顺序写。

话说写 AOF 是顺序写的么？

[IwfWcf]

@styx 因为我想测试在 AOF 的情况下 pwrite 的性能表现，AOF 当然是顺序写了。我主要的疑问在于为什么使用 Direct I/O 的情况下 pwrite 的耗时减少了一半，以及为什么在非 Direct I/O 的情况下 pwrite 的耗时要比 write 慢很多。既然 Direct I/O 的情况下 pwrite 和 write 的耗时是相当的，那说明在 AOF 的情况下 disk seek 的时间应该是可以忽略的，那为什么在非 Direct I/O 的情况下 pwrite 要慢那么多呢？

[IwfWcf]

@styx 要用 pwrite 进行 appeend 操作是因为有这样一个场景，大多数的写都是 AOF，但还是会有少量的随机写，所以我想知道在这种场景下使用 pwrite 的性能影响

[styx]

@IwfWcf pwrite 其实比 write 少了读取和更新文件 pos 的调用，其余的都和 write 差不多，我感觉 pwrite 比 write 还要简单。所以 pwrite 和 write 的比较我也有点不解。

然后 Direct 每次都要等待磁盘的操作完成（可能还在磁盘的 cache 里），所以按理说应该每一次写的延迟都比较大，毕竟有 page cache 的时候 write 可以只要写内存，延迟更小。所以打开 Direct 反而变快也比较反直觉。

没帮上什么忙，我觉得会不会考虑一些别的因素，比如会不会 page cache 太小导致一次的可以完成的几个页 Direct IO 被拆成几次的 page cache flush？

[IwfWcf]

@styx 我下午又再跑了几次，现在不会出现不使用 Direct I/O 的 pwrite 比使用 Direct I/O 的 pwrite 慢的情况了。而当把写的数据量级从 10G 提高到 100G 后也不会出现 pwrite 比 write 慢很多的情况了。应该主要是我之前测试时写的数据量级不够大的影响。