O / S刷新Chronicle文件到磁盘导致非常高的延迟?

时间:2017-08-07 20:49:11

标签: java linux chronicle-queue

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

有一天,我们的客户似乎随意地报告了应用程序中2.5秒的响应能力(我们已经运行了很多个月而没有发生这种情况)。我们在延迟时检查了 atop 文件,并看到当时正在运行flush命令的进程。 ( atop 的屏幕截图发布在下方。)

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

如果发生了这种情况,我们不确定是什么原因造成了Chronicle的冲洗,因为当时有大量的空闲内存(从125G中释放出110G)。

所以问题是:

  1. 有没有办法知道Chronicle什么时候被刷新到磁盘?

  2. 哪些因素会造成如此长的冲洗时间? (这几个月似乎只发生过一次。)

  3. ATOP SCREEN SHOT Atop screen shot

1 个答案:

答案 0 :(得分:1)

我们支持队列3.x已经有一段时间了,但是有一些代码会导致刷新,但只有在用户要求时才应该这样做。 注意:4.x还没有此功能,但添加它是一项非常出色的任务。

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

默认情况下,btw在Linux上只允许10%的内存在5到30秒之间变脏。我怀疑是否有一些活动导致太多页面被弄脏了太长时间,导致他们需要立即刷新并防止更多页面被弄脏并且暂停进程。

您可以增加此限制,但我通常建议投资SSD。这些天你可以以1英镑左右的价格镜像1 TB。