I/O のミスアライメントによるデータベースロギングとは何ですか。

環境

ONTAP OS

回答

NetApp ファイラーのパフォーマンスの問題に関しては、ファイラーのパフォーマンスが低下する一般的な原因の 1 つが部分的な書き込みです。Data ONTAP と WAFL は、通常、ユーザの書き込み要求を迅速に完了できます。これは、書き込みが NVRAM に書き込まれた時点で正常に格納されることが保証されるためです。この処理は通常 1 ミリ秒未満で、 NAS および SAN のユーザーに高速な書き込みパフォーマンスを提供します。

これは、 4K WAFL ブロック境界で書き込み要求が開始され、 4K で割り切れることがあり、サイズが 4K 未満であることを前提としています。この条件が満たされていない場合の結果は、部分的な書き込みです。部分的な書き込みには、読み取り、データのマージ、データの読み取り、結果の新しいブロックへの書き込みが含まれます。このプロセスでは、書き込みが中断される可能性があります。中断されない場合は、処理に時間がかかり、レイテンシが長くなります。

 

部分的な書き込みの一般的なソースは、ミスアライメントされた LUN I/O ですミスアライメントさtats perfstat_lunれた I/O のインジケータは、 perfstat のセクションのライトアライメントヒストグラムにある LUN です。

OEM メモ 

アライメントされていない I/O の詳細については、 KB: What is an unaligned I/O ? を参照してください。

この記事では、 MS SQL （またはその他のデータベース）のログ書き込みによってミスアライメント I/O が発生した場合と、それらが Filer のパフォーマンスに影響を及ぼすかどうかを判断する方法について説明します。 

このタイプの I/O は、一般write_partial_blocksに、一定の割合のを持つ、複数の非 0 バケットに到達する書き込みとして認識されます。 

lun:/vol/sql_log/lundggtHJeWTKaT:write_align_histo.0:0% 

lun:/vol/sql_log/lundggtHJeWTKaT:write_align_histo. 1:4% 

lun:/vol/sql_log/lundggtHJeWTKaT:write_align_histo.2:0% 

lun:/vol/sql_log/lundggtHJeWTKaT:write_align_histo. 3:6% 

lun:/vol/sql_log/lundggtHJeWTKaT:write_align_histo.4:0% 

lun:/vol/sql_log/lundggtHJeWTKaT:write_align_histo. 5:57% 

lun:/vol/sql_log/lundggtHJeWTKaT:write_align_histo. 6:21% 

lun:/vol/sql_log/lundggtHJeWTKaT:write_align_histo.7:0% 

lun:/vol/sql_log/lundggtHJeWTKaT:read_partial_blocks: 4% 

lun:/vol/sql_log/lundggtHJeWTKaT: write_partial_blocks:6%

 

通常、上記のように表示されるヒストグラムは、ミスアライメントされた LUN として誤って解釈されますが、 LUN タイプをさらに調査すると、ホストアプリケーションに適した LUN であることがわかります。実際、上記のパターンは、データベースログアプリケーションでは一般的です。この場合、 MS SQL Server のトランザクションロギングについて説明しますが、これらのプリンシパルは他のデータベースアプリケーションやその他のワークロードにも適用されることがあります。

 

この記事では、このような状況で頻繁に発生する質問に回答します。

 

「 LUN が正しいタイプで、ホスト側で適切にアライメントされていることが確認された場合、この LUN にはなぜミスアライメントされた I/O があるのですか」

 

この例では、 Windows 2008 サーバを検討します。NetApp LUN タイプは Windows_2008 にする必要があります。この LUN 上に作成された NTFS ファイルシステムへの I/O は、デフォルトで開始オフセットが修正され、 NTFS ではシステムバッファキャッシュが使用されるため、自動的にアライメントされる必要があります。これにより、書き込み処理が 4K で割り切れることが保証されます。

 

では、この NTFS パーティションに SQL Server のログを記録すると、 NTFS で適切にアライメントされた書き込みが保証された場合に、どのようにして I/O のミスアライメントが発生しますか

 

その答えは、 Windows の CreateFile 関数がFILE_FLAG_NO_BUFFERING、ファイルの読み取り時または書き込み時にこのシステムキャッシュを無効にするフラグを提供することです。現在使用可能な SQL Server のバージョンではこのフラグが使用されており、整合の問題に常に対処するわけではないため、書き込みが整合しないことがあります。このフラグの詳細について[1]は、 Microsoft のファイルバッファリングに関する記事を参照してください。

 

SQL Server のトランザクション・ロギングでは、ミスアライメントされた I/O が作成されますが、必ずしも Filer のパフォーマンスに大きな影響を与えるとは限りません。たとえば、次の図では、 SQL ログのバッチで構成される 512K SAN ブロックの書き込みを示しています。

 

 

注： 512K の SAN 書き込みでは、 1284K WAFL ブロックが消費されます。SAN ブロックがミスアライメント状態write_align_histo.5になった場合は、上記の最初の WAFL ブロックのバケット 5 で開始される WAFL ブロックの中央から開始され、その処理はミスアライメントとみなされ、（バケット 5 ）に表示されます。また、この要求の処理に使用される最初と最後の WAFL ブロックは、部分的な書き込みです。ただし、これら 2 つの部分的なブロックについては、 126 個の非部分的なブロックが存在するため、このシナリオでの影響は最小限です。

 

ライトアライメントのヒストグラムを評価する場合は、 LUN の平均処理サイズを考慮する必要があります。上記のシナリオに基づいて、運用サイズを大きくすると、運用サイズを小さくするよりも影響が小さくなります。

 

Filer に実際に与える影響の程度を確認するには、 wafl_susp -w の次の統計を確認します。

 

• pw.over_limit wp.partial_writeカウントがを超えた場合partial_write_limitの発生回数です。partial_write_limit以前は 50 に修正されていましたが、新しいバージョンの Data ONTAP ではプラットフォームに依存しています。
• WAFL_WRITE wafl_write反復処理中に Filer が受信した新しいメッセージの実際の数です。

 

pw.over_limit wafl_writeと新しいメッセージの関係は絶対的でpw.over_limitWAFL_WRITEはありませんが、経験則として、新しいメッセージに対するの比率を計算することで影響を判断できます。

 

例：

pw.over_limit = 90145

 

WAFL_WRITE (from â??New Messagesâ?? section) = 603444

 

90145 / 603444\xa0= .15 or 15%

 

この場合、新しい WAFL 書き込みが 100 回行われるたびに、データをマージして書き込みを完了するために、約 15 回のブロックを同期的に読み取る必要があります。これは、単にデータを NVRAM に書き込むだけの場合と比較した場合です。WAFL では、書き込み確認をブロックせずに、少数の部分書き込みを非同期で処理しますが、 WAFL では未処理の部分書き込みが 50 回を超えると、これらの処理が同期的に開始され、書き込みの完了に要する時間が大幅に増加します。pw.over_limitこれらの書き込みはカウンタに反映されます。上記の割合が高いほど、パフォーマンスに影響する可能性が高くなります。パフォーマンスへの影響を発生pw.over_limit/wafl_write 'させるために必要な割合は、いくつかの要因によって異なります。したがって、ハイウォーターマークはでは宣言できません。

追加情報

AdditionalInformation_Text