2011-03-11 53 views
3

我們有一個非常延遲敏感的應用程序,在上讀取等待時間尖峯感覺非常非常糟糕。讀延遲()

我測試過XFS和EXT4,寫O_ASYNC到該文件,然後fdatasync()在最後會導致讀取延遲1秒以上的尖峯!

我又試圖O_SYNC,我得到了更加穩定的讀取延遲,但寫入文件非常慢。

所以,我試着寫O_ASYNC並同步每寫入5 MB的文件,其快速和讀取延遲也相當穩定。

不過30分鐘,我仍然可以得到讀取,需要一個第二個或更多。

如果你在Linux上構建延遲敏感型應用,你是如何處理與文件系統的工作,還是你只是不是在所有使用它,並安裝該設備作爲原始設備?

+0

什麼是底層硬件?磁盤還是閃存? – 2011-03-11 14:28:28

+0

ssd。不旋轉磁盤。這是我第一次使用與文件系統性能明顯緊密結合的應用程序。我想,即時通訊只是對保證讀取延遲的不同方式感到好奇......我會研究更多關於此的實時文件系統...... – 2011-03-11 14:43:02

+0

您讀取的數據量是多少,速度是多少?所有數據都在一個現有文件中,還是在另一個進程寫入文件時讀取該文件? – 2011-03-11 14:51:16

回答

0

一個文件系統總是會增加延遲量小,所以對於一個真正的延遲敏感的應用程序,我會考慮使用原始設備或打開與O_DIRECT繞過操作系統的緩存文件繞過文件系統。

對SSD存儲延遲其他招數:

  • 通過閱讀使用現代固態硬盤固有的並行/從多個線程編寫。等待時間不會減少,但如果真正的問題是IOPS,則會有所幫助。
  • 檢查SSD上文件系統的對齊情況。如果做得不對,您的性能就會降低一半,延遲也會加倍。
  • 檢查磁盤調度算法。 Linux「noop」調度程序通常是基於SSD的存儲的最佳選擇。
  • 使用更好的SSD硬件,例如基於PCIe的SSD通常提供更低的延遲

這就是說:從第二個讀取時間聽起來不正確。無論是負載/利用率如此之高,硬件根本無法應付它,更多/更好的硬件將是最好的解決方案,或其他問題是非常錯誤的。