java - O/S 将 Chronicle 文件刷新到磁盘导致非常高的延迟？

Question

我们在低延迟应用程序(在 Linux Centos 机器上)中使用 Vanilla Chronicle Queue 版本 3.6.0。

有一天，我们的客户似乎是随机的，报告应用程序中有 2.5 秒的响应时间不足(我们已经运行了好几个月而没有发生这种情况)。我们检查了延迟时间的atop 文件，看到当时有一个进程正在运行flush 命令。 (来自 atop 的屏幕截图发布在下方。)

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

如果发生这种情况，我们不确定是什么原因导致 Chronicle 刷新，因为当时有大量可用内存(125G 中有 110G 可用)。

所以问题是:

1. 有没有办法知道 Chronicle 何时/是否刷新到磁盘？

2. 什么因素会导致冲洗时间这么长？ (这几个月似乎只发生过一次。)

屏幕截图

Answer 1

自从我们支持队列 3.x 以来已经有一段时间了，但是有一些代码会导致刷新，但只有在用户要求时才应该这样做。注意:4.x 还没有这个功能，但添加它是一项艰巨的任务。

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

顺便说一下，在 Linux 上，默认情况下只有 10% 的内存被弄脏 5 到 30 秒。我怀疑有大量 Activity 导致太多页面脏了太久，导致它们都需要立即刷新并防止更多页面被弄脏和进程暂停。

您可以增加此限制，但我通常建议投资购买 SSD。这些天你可以用大约 1000 英镑镜像 1 TB。