我们在低延迟应用程序中使用 Vanilla Chronicle Queue 版本3.6.0(在Linux Centos机器上)。
有一天,我们的客户似乎随意地报告了应用程序中2.5秒的响应能力(我们已经运行了很多个月而没有发生这种情况)。我们在延迟时检查了 atop 文件,并看到当时正在运行flush
命令的进程。 ( atop 的屏幕截图发布在下方。)
我们猜测O / S将Chronicle内存页面刷新到磁盘,这阻止了我们的处理线程继续,直到刷新完成。另一条指向相同结论的信息是,内部应用程序统计数据似乎表明在线程将新条目写入Chronicle的处理点发生了延迟。
如果发生了这种情况,我们不确定是什么原因造成了Chronicle的冲洗,因为当时有大量的空闲内存(从125G中释放出110G)。
所以问题是:
答案 0 :(得分:1)
我们支持队列3.x已经有一段时间了,但是有一些代码会导致刷新,但只有在用户要求时才应该这样做。 注意:4.x还没有此功能,但添加它是一项非常出色的任务。
如果任何进程调用同步,则可能导致在某些操作系统上刷新所有内存。
默认情况下,btw在Linux上只允许10%的内存在5到30秒之间变脏。我怀疑是否有一些活动导致太多页面被弄脏了太长时间,导致他们需要立即刷新并防止更多页面被弄脏并且暂停进程。
您可以增加此限制,但我通常建议投资SSD。这些天你可以以1英镑左右的价格镜像1 TB。