我有一个 Java 应用程序，它向ext3 SAN 文件系统中的大约十几个文件执行大量（数百 MB）的连续输出（流式纯文本） 。有时，此应用程序会一次暂停几秒钟。我怀疑与ext3 vsfs（Veritas 文件系统）功能（和/或它与操作系统的交互方式）相关的某些事情是罪魁祸首。
我可以采取什么步骤来证实或反驳这个理论？我知道iostat并/proc/diskstats作为起点。
修改标题，不再强调日志记录，而是强调“停顿”
我进行了一些谷歌搜索，发现至少有一篇文章似乎描述了我观察到的行为：解决 ext3 延迟问题
附加信息
- Red Hat Enterprise Linux 服务器版本 5.3 (Tikanga)
- 核心：
2.6.18-194.32.1.el5 - 主要应用磁盘是光纤通道 SAN：
lspci | grep -i fibre>>14:00.0 Fibre Channel: Emulex Corporation Saturn-X: LightPulse Fibre Channel Host Adapter (rev 03) - 安装信息：
type vxfs (rw,tmplog,largefiles,mincache=tmpcache,ioerror=mwdisable) 0 0 cat /sys/block/VxVM123456/queue/scheduler>>noop anticipatory [deadline] cfq
答案1
我的猜测是，有一些其他进程会占用磁盘 I/O 容量一段时间。 iotop如果您的内核足够新，可以帮助您查明原因。
如果是这种情况，那与文件系统无关，更与日志无关。I/O 调度程序负责在冲突的应用程序之间进行仲裁。一个简单的测试：检查当前调度程序并尝试不同的调度程序。它可以即时完成，而无需重新启动。例如，在我的桌面上检查第一个磁盘（/dev/sda）：
cat /sys/block/sda/queue/scheduler
=> noop deadline [cfq]
显示它正在使用 CFQ，这对于台式机来说是个不错的选择，但对于服务器来说则不然。最好设置“截止日期”：
echo 'deadline' > /sys/block/sda/queue/scheduler
cat /sys/block/sda/queue/scheduler
=> noop [deadline] cfq
等待几个小时，看看是否有所改善。如果是，请在启动脚本中永久设置它（取决于发行版）
答案2
一个简单的测试就是将那个 ext3 fs 安装为 ext2，然后分析应用程序的性能。
答案3
答案是“是”（日记总是增加了延迟 :-)
它有多重要这个问题实际上只能通过直接测试来回答，但通常假设每个（日志记录）操作所花费的时间大约是不启用日志记录的两倍。
由于您在评论中提到另一个答案您无法在生产环境中进行直接测试（并且可能没有可用的开发/测试环境），但您还有另一个选择：查看磁盘统计信息，看看您花了多少时间写入日志设备。
不幸的是，这只有在您的日志设备是独立的并且可以与“主”磁盘分开进行检测时才真正有用。
今天我第二次插入 McKusick 的视频，但如果你仔细阅读这个视频那里有关于日志文件系统必须完成的一些工作（以及相关的性能影响）的精彩讨论。虽然
对您和您的特定问题没有直接用处/相关性，但提供了有关文件系统和日志的精彩背景知识。
答案4
我在使用 ext3 文件系统的 Redhat 4 上遇到了这个问题：在 ext3 文件系统上进行多次写入 => 在另一个 ext3 FS 写入上等待很长时间
通过访问时间更新，读取访问也可以暂停 => 解决方法：mount -o noatime
问候，杰罗姆·D。