Azure NetApp Files 的 Linux 直接 I/O 最佳做法
本文協助您了解 Azure NetApp Files 的直接 I/O 最佳做法。
直接 I/O
儲存體效能評定中最常用的參數是直接 I/O。 FIO 和 Vdbench 支援它。 DISKSPD 支援記憶體對應 I/O 類似的建構。 直接 I/O 可以略過檔案系統快取、避免直接記憶體存取複製的作業，以及快速又簡單完成儲存體測試。
使用直接 I/O 參數可以輕鬆完成儲存體測試。 用戶端不需要從檔案系統快取讀取任何資料。 因此，測試確實強調儲存體通訊協定和服務本身，而不是記憶體存取速度。 若沒有 DMA 記憶體複本，讀取和寫入作業會從處理的觀點來看有效率。
以 Linux dd 命令的工作負載為例。 如果沒有選用的 odirect 旗標，則會從 Linux 緩衝區快取提供 dd 產生的所有 I/O。 未從記憶體擷取具有記憶體中區塊的讀取。 如果讀取導致緩衝區快取遺漏，則最後會使用 NFS 預先讀取來讀取，並產生不同的結果，視掛接 rsize 和可調整的用戶端預先讀取等因素而定。 透過緩衝區快取傳送寫入時會使用事後寫入機制，此機制不調整，而且使用大量的平行處理原則將資料傳送至存放裝置。 您可以嘗試執行兩個獨立的 I/O 資料流，一個 dd 用於讀取，另一個 dd 用於寫入。 但事實上，不調整的作業系統偏好寫入而非讀取，並使用更多平行處理原則。
除了資料庫之外，很少應用程式會使用直接 I/O。 相反地，它們會利用大型記憶體快取的優點進行重複讀取，以及異步寫入的快取後置寫入。 簡單地說，「如果」建構中的應用程式使用檔案系統快取，則使用直接 I/O 會將測試變成微基準。
以下是支援直接 I/O 的一些資料庫：
- Oracle
- SAP HANA
- MySQL (InnoDB 儲存引擎)
- RocksDB
- PostgreSQL
- Teradata
最佳作法
測試 directio 是了解儲存體服務和用戶端極限的好辦法。 若要進一步瞭解應用程式的行為（如果應用程式不使用 directio），您也應該透過檔案系統快取執行測試。