ディスクサブシステムは最も一般的なボトルネックです。I/Oは長いキューに対して比較的長い時間がかかり、ディスクの高使用率やCPUサイクルのアイドリングにつながります。予想されるピーク負荷時にiostatツールを使用し、平均応答時間の指標を測定してください。
ディスクの読み込み、書き込みおよび更新操作は連続的であるか、またはランダムです。ランダムな読み込みおよび更新は、eDirectoryの展開のなかで最も一般的なアクセスパターンです。
ランダムワークロードに対するソリューション:
RAMを増やす。これにより頻繁に使用するデータや先読みデータをファイルシステム層にキャッシュすることができるようになります。また、DIBをFLAIMサブシステム内にキャッシュすることもできるようになります。
DIBに専用のボリュームを使用する。スピンドル付近に生成されたボリュームに対して、ファイルシステムパフォーマンスが向上します。RFLおよび他のログに専用のボリュームを使用する。
時間が経過するにつれ、フラグメンテーションによりディスクのレイテンシが増加するので、デフラグメントを行う必要があります。
FLAIM RFLのために別個のディスクドライブを追加する。このタイプのログ記録は高速ディスク上で実行できます。
より多くのディスクドライブで、RAID 10(1+0)を使用する。
eDirectoryが作成するファイルは4GBまで増大することがあります。大きなファイルに対処できるよう最適化されたファイルシステムは、eDirectoryと効率的に連携できます。
Solaris™のVeritas* VxFSファイルシステムはエクステントベースのファイルシステムで、ファイルシステムメタデータは大きなファイルに対して最適化されています。UFSファイルシステムは間接的なブロックベースで、ファイルシステムメタデータは多数のブロック内に保存されます。大きなファイルに散乱させられることさえあり、より大きなファイルに対してUFSはさらに遅くなります。
Linux™のReiserファイルシステムは高速なジャーナリングファイルシステムで、大きなDIB集合に対してext3ファイルシステムよりもパフォーマンスが優れています。とはいえ、ext3のライトバックジャーナリングモードはReiserファイルシステムのパフォーマンスに匹敵することが知られています。ただデフォルトのオーダードモードはより優れたデータの整合性を実現します。XFSはハイパフォーマンスのジャーナリングファイルシステムで、大きなファイルを処理し、円滑なファイル転送を実現できます。eDirectory 9.0は、XFSファイルシステムを持つSLES 11 32ビットおよび64ビットプラットフォームをサポートしています。
FLAIMは、4KBおよび8KBのブロックサイズをサポートしています。デフォルトは4KBです。これはLinuxでのデフォルトのブロックサイズと同じです(tune2fs -1 device)。Solarisでは、UFSファイルシステムは8KBのデフォルトブロックサイズで生成されます(df -g mountpoint)。FLAIMのブロックサイズがファイルシステムのブロックサイズよりも小さい場合、ブロックへの部分的な書き込みが発生することがあります。データベースのブロックサイズがファイルシステムのブロックサイズよりも大きい場合、各ブロックの読み込みおよび書き込みは、連続した別個の物理的I/O操作に分割されてしまいます。そのため、FLAIMのブロックサイズは必ずファイルシステムのブロックサイズと同じにするべきです。
ブロックサイズは、DIBの作成時にのみ調整することができます。「blocksize=8192」という行を_ndsdb.iniに追加し、8KのブロックサイズでDIBを作成してください。
適切なブロックサイズは、展開でのFLAIMレコードの平均サイズによって決まります。展開に適切なブロックサイズを判断するために、テストデータの適切な集合に対する実験的テストが必要です。