Java O/S将历史记录文件刷新到磁盘会导致很高的延迟吗？

我们在低延迟应用程序（Linux Centos机器上）中使用香草纪事队列3.6.0版

有一天，我们的客户报告说，该应用程序的响应时间不足2.5秒，这似乎是随机的（我们已经运行了好几个月，没有出现这种情况）。我们在延迟时检查了top文件，发现当时有一个进程正在运行

flush

命令。（顶部的屏幕截图张贴在下面。）

我们猜测O/S将历史记录内存页刷新到磁盘，这阻止了我们的处理线程继续，直到刷新完成。另一条指向相同结论的信息是，内部应用程序统计数据似乎显示延迟正好发生在线程将新条目写入历史记录的处理点上

如果是这样的话，我们不确定是什么导致了历史记录刷新，因为当时有很多可用内存（125G中有110G可用内存）

因此，问题是：

有没有办法知道何时/是否将历史记录刷新到磁盘

什么因素会导致如此长的冲洗时间？（这几个月似乎只发生过一次。）

顶部屏幕截图

---

我们已经有一段时间不支持队列3.x了，但是有一些代码会导致刷新，但只有在用户要求时才会刷新。 注意：4.x还没有这个特性，但是添加它是一项杰出的任务

如果任何进程调用同步，它可能会导致某些操作系统上的所有内存被刷新

顺便说一句，在linux上，默认情况下，只有10%的内存允许在5到30秒内变脏。我怀疑有一个突发的活动，留下太多的页面脏了太长时间，导致他们都需要一次冲洗，防止更多的页面被弄脏和进程暂停

---

你可以增加这个限制，但我通常建议你投资SSD。现在，您可以用大约1k英镑镜像1 TB。

两个后续问题：1-我们应该使用不同的历史记录版本吗？（Maven 3.6.4似乎是最新发布的版本）。2-如果发生的是有太多脏页（在所有应用程序中），刷新是不可避免的，SSD将大大缩短刷新时间——你有什么统计数据表明可能会有什么不同（真实或猜测）？感谢您对这个问题的回答。@SamGoldberg SSD最明显的区别是99%的ile为Tytplicy 1/10。一般来说，客户端不支持高传输速率，并且拥有大内存服务器。例如，0.25到0.5 TB的主内存，因此10%的内存比磁盘上的内存至少提前25 GB。由于单个SATA SSD可以支持大约0.5 GB/s的速度，因此允许非常大的突发。如果您使用NVMe，您可以以1-2 GB/s的速度持续写入@SamGoldberg我们不再支持3.x，建议您尝试v4。常规版本仅对受支持的客户端可用。我预计我们将在9月底向maven central发布另一个版本。