PRIMECLUSTER Global File Services 説明書 4.1 (Solaris(TM) オペレーティング環境版）

9.2.2 性能検証

　GFS ローカルファイルシステムでは、内部的なコンポーネントとして

1. ファイルシステム操作部
2. ファイル操作部
3. ファイルデータの管理部
4. メタデータのキャッシュ管理部
5. メタデータのディスク更新部(メタデータ書き込みデーモン：メタデーモン)
6. アップデートログのメモリ記録部
7. アップデートログのディスク更新部(ログ書き込みデーモン：ログデーモン)

に分かれています。

　ファイルシステムの性能を監視する場合には、これら個々の部分について性能的なネックが発生していないか調べる必要があります。

a) ファイルシステム操作部

　ファイルシステム操作部に関しては、マウント、アンマウント、sync などのオペレーションに関与します。

　マウント、アンマウントについては一般的に性能上の問題を考慮する必要はありません。GFS ローカルファイルシステムの場合、sync 要求時にログ書き込みデーモンへディスクへの反映を要求した回数を sfxstat(1M) で確認することができます。ユーザが明示的に sync(1M) ないしは sync(2) システムコールを頻繁に実行するように指定している場合に、ログ書き込みデーモンの起動要求の多数を占め、ログ書き込み I/O ネックとなっている場合には、呼出し回数の見直しを行うことを検討してください。

b) ファイル操作部

　ファイル操作部については read/write システムコールの回数は sar(1M) の -c オプションにより、システム全体での呼出し回数が確認できます。

　他のシステムコールについては個別の情報は求められません。

c) ファイルデータの管理部

　ファイルデータの管理部についてはディスクに対しての read/write の発行回数とブロック数 (8 キロバイト単位) を sfxstat(1M) の -i オプションで知ることができます。

　GFS ローカルファイルシステムでは、ファイルのデータ部に関しては極力、連続読み込み、連続書き込みになるようにファイルデータの割り付けを行っていますが、領域獲得状態により連続領域にならないことがあります。

　readblks/readcnts、writeblks/writecnts が 1 に近い値の場合、データ部の割り付け状態が細切れになっている可能性があります。この場合にはファイルに対してのシーケンシャルリード/ライト性能が低下してしまいます。

　可能であれば、デフラグを実施するか sfxcp(1) コマンド等で一旦別のファイルに複製し、旧ファイルを削除後 sfxmv(1) コマンド等で同一ファイルに戻してください。これにより連続割り付け状態に戻すことができる場合があります。

　また、ダイレクト I/O 機能を使用している場合には、sfxstat(1M) の -d オプションでダイレクト I/O の読み込み回数、書き込み回数、読み込みブロック数、書き込みブロック数、読み込みが通常 I/O になった回数、書き込みが通常 I/O になった回数、読み込み後ページのフラッシュを行った回数、書き込み後ページのフラッシュを行った回数について知ることができます。

　ダイレクト I/O 機能を使用している場合のチューニングに関しては、I/O サイズの変更や、境界条件の変更等アプリケーション側での対応による改善方法と、上述の連続割り付け状態にすることによる改善方法が考えられます。

d) メタデータのキャッシュ管理部

　メタデータのキャッシュ管理部についてはメタデータのキャッシュ種別ごとのアクセス回数、キャッシュヒット回数、更新回数、およびメタ種別ごとの読み込み回数について sfxstat(1M) の -c オプションで知ることができます。

　メタデータのキャッシュへのアクセス回数に対してキャッシュのヒット回数が少ない場合には、システム内におけるメタデータのキャッシュ領域の不足が考えられます。

　GFS ローカルファイルシステムでは、

• エクステント領域管理 (LEAF、NODE) のキャッシュの個数
• ディレクトリデータ (DIR) のキャッシュの個数
• ディスク i ノード(DINODE) のキャッシュの個数
• quota データ (QUOTA) のキャッシュの個数

の設定が可能です。

　もし、上記領域のいずれかがキャッシュのヒット率 (cachehit/access * 100) が 30% を下回るようであれば、次節で説明するチューニングパラメタを正しく設定することで性能が改善する可能性があります。

e) メタデータのディスク更新部(メタデータ書き込みデーモン)

　メタデータのキャッシュ種別ごとの書き込み回数、書き込み時間、平均書き込み時間についてsfxstat(1M) の -c オプションで知ることができます。

　1 秒当たりの更新回数 (mod) が 100 以上の値であり、書き込み回数 (W-I/O) の比が 1 に近い場合、更新後、実際のディスクへの反映までの時間がアップデートログ領域等により保持時間が制約されている可能性があります。

　まず、sfxstat(1M) の -m オプションで mlogfull の項目が 1 分以上に渡って秒当たり 10 を越えるような場合には

• アップデートログ領域を広げる(アップデートログ領域が別パーティションの場合)
• アップデートログ領域を別パーティションにする(代表パーティションにアップデートログ領域が存在する場合)

といった対応を取ることにより、性能が改善することがあります。

　アップデートログ領域を広げるには、sfxadm(1M) を使用します。アップデートログ領域を別パーティションにするにはファイルシステムの再作成が必要です。詳しくは sfxadm(1M) および mkfs_sfxfs(1M)、sfxnewfs(1M) のリファレンスマニュアルを参照してください。

　アップデートログ領域が原因でない場合には、システム内におけるメタデータのキャッシュ領域の不足が考えられます。sfxstat(1M) の -m の METAFULL 情報でメタデータのキャッシュの種別毎に領域の枯渇が発生した回数が表示されます。

　GFS ローカルファイルシステムでは、

• エクステント領域管理 (LEAF、NODE) のキャッシュの個数
• ディレクトリデータ (DIR) のキャッシュの個数
• ディスク inode(DINODE) のキャッシュの個数
• quota データ (QUOTA) のキャッシュの個数

の設定が可能です。

　もし、上記領域のいずれかが頻繁に METAFULL 状態 (領域の枯渇が発生した回数が 1 以上) になるようであれば、次節で説明するチューニングパラメタを正しく設定することで性能が改善する可能性があります。

f) アップデートログのメモリ記録部

　アップデートログのメモリ記録部については sfxstat(1M) の -l オプションにより、

• ログバッファフル回数 (lbfull)
• トランザクション数オーバでスリープした回数 (ltfull)
• ログディスクフルでスリープした回数 (ldfull)
• 先行トランザクションが大きいためスリープした回数 (logbig)
• 先行トランザクションが巨大化したためにスリープした回数 (logbigx)
• ログ対象処理要求回数 (lntrans)、ログ対象処理の並行動作数 (lpara)
• 平均並列動作数 (lave)、巨大バッファ使用回数 (lbigbuf)
• サブトランザクション発生回数 (lsubtrn)

について知ることができます。

　ldfull が頻繁に 0 以外になる場合には g) のディスク更新部について見直しを行うことにより性能が改善することがあります。

g) アップデートログのディスク更新部(ログ書き込みデーモン)

　アップデートログのディスク更新部(ログ書き込みデーモン)については sfxstat(1M) の -l オプションにより、

• ログデーモンの起動回数(lwakeup)
• ログデーモンが I/O 発行した回数(lnwrite)
• 書き込みにかかった時間(lms)
• 書き込みブロック数(lnblks)
• 有効ブロック数(loccupy)

について知ることができます。

　ログデーモンが I/O 発行した回数が 1 秒当たり 10 回を越え、平均 I/O 時間 (lms/lnwrite) が 100 ミリ秒を越える場合、アップデートログ領域を別パーティションとして独立させることにより性能が改善することがあります。

　アップデートログ領域を別パーティションにするにはファイルシステムの再作成が必要です。詳しくは mkfs_sfxfs(1M)、sfxnewfs(1M) のリファレンスマニュアルを参照してください。

　ldfull が頻繁に 0 以外になる場合には、アップデートログ領域を拡大(アップデートログ領域が別パーティションの場合)することで性能が改善することがあります。アップデートログ領域を拡大するには、現在使用中のファイルシステムをアンマウントした後、sfxadm(1M) の -L オプションで適切なログサイズを指定してください。詳しくは sfxadm(1M) のリファレンスマニュルを参照してください。