O/S沖洗記錄文件到磁盤導致非常高的延遲？

我們在低延遲應用程序（在Linux Centos機器上）使用Vanilla Chronicle隊列，版本3.6.0。我們的客戶報告說，有一天，我們的客戶報告在應用程序中缺乏響應2.5秒（我們已經運行了很多個月，但沒有發生這種情況）。我們在延遲時間檢查了文件的頂部，並看到當時進程正在運行flush命令。（截屏來自頂上如下公佈。）O/S沖洗記錄文件到磁盤導致非常高的延遲？

大家都在猜測，該O/S刷新紀事內存頁到磁盤，這阻礙了我們的處理線程持續，直到沖洗完成。另一條指向相同結論的信息是，內部應用程序統計信息似乎顯示在線程向Chronicle寫入新條目的處理點處發生延遲。

如果這是發生了什麼，我們不確定是什麼導致了Chronicle刷新，因爲當時有大量的空閒內存（125G中有110G空閒）。

所以問題是：

有沒有辦法當/如果紀事被刷新到磁盤，知道嗎？
什麼因素會導致如此長的沖洗時間？（這似乎已在這幾個月只有一次發生了。）

ATOP截屏

來源

2017-08-07 Sam Goldberg

這已經有一段時間，因爲我們支持隊列3.x中，但有一些代碼，會導致刷新，但只有在用戶要求時才應該這樣做。注意：4.x還沒有此功能，但添加它是一項突出的任務。

如果任何進程調用同步，它可能會導致所有內存在某些操作系統上刷新。

順便說一句，默認情況下，只有10％的內存被允許在Linux上5到30秒之間變髒。我懷疑有一段時間的活動讓很多頁面太髒，導致它們都需要立即刷新，並防止更多的頁面被弄髒，並且過程暫停。

您可以增加此限制，但我通常建議投資SSD。這些日子你可以鏡像1TB大約1K。

來源

2017-08-08 06:55:54

兩個後續問題：1-我們應該使用不同的Chronicle版本嗎？（在Maven 3.6.4上似乎是最新發布的版本）。 2-如果發生的事情是所有應用程序中的髒頁太多，並且刷新是不可避免的，並且SSD會大大縮短刷新時間 - 您是否有任何統計信息可能存在差異（真實或猜測）？感謝您對這個問題的迴應。 –

@SamGoldberg SSD最明顯的區別在於99％的版本是1/10。一般來說，客戶端不能保持高傳輸速率，並且擁有大容量的內存服務器，例如0.25到0.5TB的主內存，因此10％是至少比磁盤上的內存高出25GB的突發。由於單個SATA SSD可以維持大約0.5 GB/s，因此可以實現非常大的突發。如果你使用NVMe，你可以以1-2 GB/s的速度持續寫入（直到用完空間） –

@SamGoldberg我們不再支持3.x，我建議你嘗試v4。 HTTPS：//search.maven。org /＃search％7Cgav％7C1％7Cg％3A％22net.openhft％22％20AND％20a％3A％22chronicle-queue％22常規版本僅適用於受支持的客戶端。我預計9月底我們還會有另一個版本發佈給maven central。 –

O/S沖洗記錄文件到磁盤導致非常高的延遲？

回答

相關問題