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 フラグがない場合、dd で生成された I/O はすべて Linux バッファー キャッシュから提供されます。 既にメモリ内にあるブロックに関する読み取りは、ストレージからは取得されません。 バッファー キャッシュのミスが発生した読み取りは、NFS 先読みの使用してストレージから読み取られますが、その結果は rsize のマウントやクライアントの先読み調整項目などの要因によって変わります。 書き込みがバッファー キャッシュを経由して送信されるときは、書き込み遅延メカニズムが使用されます。これは調整されず、データをストレージ デバイスに送信するために大量の並列処理が使用されます。 読み取り用の dd と書き込み用の dd の 2 つの独立した I/O ストリームを実行する場合があります。 ただし、実際には、調整されていないオペレーティング システムによって、読み取りよりも書き込みが優先され、より多くの並列処理が使用されます。
データベースを除けば、ダイレクト I/O を使用するアプリケーションはほとんどありません。 その代わりとして、繰り返しの読み込みでは大容量のメモリ キャッシュ、非同期の書き込みではライトビハインド キャッシュの利点が活用されます。 つまり、"もし" 合成されるアプリケーションにファイルシステム キャッシュが使用されている場合に、ダイレクト I/O を使用すると、テストはマイクロ ベンチマークに変わります。
ダイレクト I/O をサポートしているデータベースの例を次に示します。
- Oracle
- SAP HANA
- MySQL (InnoDB ストレージ エンジン)
- RocksDB
- PostgreSQL
- Teradata
ベスト プラクティス
directio を使用したテストは、ストレージ サービスとクライアントの制限を理解するために推奨される方法です。 (アプリケーションが directio を使用しない場合の) アプリケーションの動作を理解するには、ファイルシステム キャッシュを通したテストも実行する必要があります。