1

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

有一天，似乎是随机的，我们的客户报告说应用程序中缺少 2.5 秒的响应（我们已经运行了好几个月没有发生这种情况）。我们在延迟时检查了顶层文件，发现当时有一个进程正在运行该flush命令。（上面的屏幕截图发布在下面。）

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

如果发生这种情况，我们不确定是什么导致了 Chronicle 刷新，因为当时有很多可用内存（125G 中有 110G 可用）。

所以问题是：

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

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

顶部屏幕截图 屏幕截图上方

4

1 回答 1

1

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

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

顺便说一句，默认情况下，Linux 上只允许 10% 的内存在 5 到 30 秒之间变脏。我怀疑有一个活动爆发，导致太多页面脏了太久，导致它们都需要一次刷新，并防止更多页面被弄脏并暂停进程。

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

于 2017-08-08T06:55:54.847 回答