ファイル・システム性能をチューニングするには,アプリケーションとユーザがどのようにディスクの入出力を実行するかを理解していなければなりません (1.8 節で説明)。 また,使用するファイル・システムがプロセスとの間でメモリを共有する方法 (第 12 章で説明) について理解していなければなりません。 この情報を利用すると,この章で説明するカーネル・サブシステム属性の値を変更することで,ファイル・システムの性能を改善できます。
この章では,次のような項目をチューニングする方法について説明します。
カーネルは,最近アクセスされたデータをメモリにキャッシュ (一時的に保管) します。 データは何度も再使用され,ディスクからデータを取得するよりもメモリから取得するほうが高速なので,データをキャッシュすると効率が上がります。 カーネルがデータを必要としているときには,まずデータがキャッシュされているかどうかをチェックします。 データがキャッシュされていれば,すぐにそのデータが返されます。 キャッシュされていなければ,ディスクからデータが取得されキャッシュされます。 データがキャッシュされ後で再使用される場合に,ファイル・システムの性能が向上します。
キャッシュ内に見つかったデータをキャッシュ・ヒットといいます。 キャッシュされたデータの効率は,キャッシュのヒット率で計測します。 キャッシュ内に見つからなかったデータはキャッシュ・ミスといいます。
キャッシュされるデータには,ファイルに関する情報,ユーザまたはアプリケーションのデータ,メタデータ (ファイルなどのオブジェクトを記述するデータ) などがあります。 キャッシュされるデータのタイプを,以下のリストに示します。
ファイル名と,それに対応する vnode は namei キャッシュにキャッシュされます (11.1.2 項)。
UFS のユーザおよびアプリケーションのデータと,AdvFS のユーザおよびアプリケーションのデータとメタデータは,ユニファイド・バッファ・キャッシュ (UBC) にキャッシュされます (11.1.3 項)。
UFS ファイルのメタデータは,メタデータ・バッファ・キャッシュにキャッシュされます (11.1.4 項)。
AdvFS のオープン・ファイル情報はアクセス構造体にキャッシュされます (11.1.5 項)。
表 11-1
では,キャッシュ情報の表示と管理に使用するコマンドを説明します。
表 11-1: キャッシュ情報を表示するツール
ツール | 説明 | 参照先 |
|
namei キャッシュの統計情報を表示する。 | |
|
仮想メモリの統計情報を表示する。 | |
|
メタデータ・バッファ・キャッシュの統計情報を表示する。 |
仮想ファイル・システム (VFS) は,下位ファイル・システム・レイヤから抽出した統一カーネル・インタフェースをアプリケーションに提供します。 その結果,ファイルのアクセスでのファイル・システムの種類の違いは,ユーザには見えなくなります。
VFS は
vnode
という構造体を用いて,マウントされたファイル・システム内の各オープン・ファイルに関する情報を保持します。
アプリケーションがファイルの読み取りまたは書き込み要求を発行すると,VFS は vnode 情報を用いて要求を変換し,それを適切なファイル・システムに渡します。
たとえば,アプリケーションがファイルに対する
read()
システム・コールを発行すると,VFS は vnode 情報を用いてシステム・コールを,ファイルが置かれているファイル・システムに対して適切な呼び出しに変換します。
UFS の場合は
ufs_read()
,AdvFS の場合は
advfs_read()
,NFS でマウントしたファイル・システムにファイルがある場合は
nfs_read()
コールに変換し,その要求を適切なファイル・システムに渡します。
VFS は最近アクセスされたファイル名とそれに対応する vnode を namei キャッシュにキャッシュします。 ファイル・システムが再使用され,ファイル名とそれに対応する vnode が namei キャッシュにある場合に,ファイル・システムの性能が向上します。
以下のリストでは,namei キャッシュに関連する
vfs
サブシステム属性を説明します。
関連する属性
vnode_deallocation_enable
-- システムの要求に応じて vnode を動的に割り当てるかどうかを指定します。
無効にすると,オペレーティング・システムは静的 vnode プールを使用します。 性能を最大にするためには,vnode の動的割り当てを無効にしないでください。
name_cache_hash_size
-- namei キャッシュのハッシュ・チェーン・テーブルのサイズをスロット数で指定します。
vnode_age
-- 解放された vnode を再利用可能とするまでの経過時間を秒数で指定します。
namei_cache_valid_time
-- namei キャッシュが破棄されるまでにキャッシュ内にとどまる時間を秒数で指定します。
注意
namei キャッシュに関連する属性の値を増やす場合は,ファイルとディレクトリの情報をキャッシュするファイル・システム属性を増やすことも検討してください。 AdvFS を使用する場合の詳細は,11.1.5 項 を参照してください。 UFS を使用する場合の詳細は,11.1.4 項 を参照してください。
チューニングするかどうかの判断
namei キャッシュの統計情報を調べると,namei キャッシュに関連する属性の値を変更すべきかどうか判断できます。
namei キャッシュの統計情報を調べるには,dbx print
コマンドを入力してプロセッサ番号を指定し,nchstats
データ構造体を調べます。
たとえば,次のコマンドを入力します。
# /usr/ucb/dbx -k /vmunix /dev/mem (dbx) print processor_ptr[0].nchstats
次のような情報が表示されます。
struct { ncs_goodhits = 18984 ncs_neghits = 358 ncs_badhits = 113 ncs_falsehits = 23 ncs_miss = 699 ncs_long = 21 ncs_badtimehits = 33 ncs_collisions = 2 ncs_unequaldups = 0 ncs_newentry = 697 ncs_newnegentry = 419 ncs_gnn_hit = 1653 ncs_gnn_miss = 12 ncs_gnn_badhits = 12 ncs_gnn_collision = 4 ncs_pad = { [0] 0 } }
dbx print
の出力に基づいて,namei キャッシュ関連の属性値をいつ変更すればよいかを,表 11-2に示します。
表 11-2: namei キャッシュ関係の属性の値を変更する時期
条件 | 増やす値 |
|
maxusers
属性または
name_cache_hash_size
属性の値 |
ncs_badtimehits
が
ncs_goodhits
の
0.1 パーセントよりも大きい |
namei_cache_valid_time
属性および
vnode_age
属性の値 |
name_cache_hash_size
属性,namei_cache_valid_time
属性,vnode_deallocation_enable
属性のいずれかを変更したときには,システムのリブートが必要です。
vnode_age
属性の値は,システムをリブートすることなく変更できます。
サブシステム属性の変更についての詳細は
第 3 章
を参照してください。
11.1.3 UBC のチューニング
ユニファイド・バッファ・キャッシュ (UBC) は,非固定メモリをプロセスと共有し,UFS のユーザおよびアプリケーション・データと,AdvFS のユーザおよびアプリケーション・データとメタデータをキャッシュします。
ファイル・システムの性能は,データおよびメタデータが再使用されて UBC 内にあった場合に向上します。
関連する属性
UBC に関連する
vm
サブシステム属性を,以下のリストに示します。
vm_ubcdirtypercent
属性 --
UBC がディスクへの書き込みを開始するときの,ダーティ (変更されている) ページの割合の最小値を指定します。
ubc_maxdirtywrites
属性 --
UBC 内のダーティ (変更されている) ページの数が
vm_ubcdirtypercent
属性を超えたときに,vm
サブシステムが実行する入出力操作の頻度 (1 秒あたりの回数) を指定します。
ubc_maxpercent
属性 --
UBC が同時に使用できる物理メモリの最大割合を指定します。
ubc_borrowpercent
属性 --
メモリの使用量がここで指定した割合を上回ると,UBC は
vm
サブシステムからメモリを借用していると見なされます。
UBC が借用ページをすべて返却するまで,ページングは発生しません。
ubc_minpercent
属性 --
UBC が使用できるメモリの最小割合を指定します。
残りのメモリはプロセスと共有されます。
vm_ubcpagesteal
属性 --
ファイルの拡張に備えて用意するページの最小数を指定します。
使用可能なページ数がこの値を下回ると,UBC はさらにページを流用して,ファイルの拡張要求に備えます。
vm_ubcseqpercent
属性 --
1 つのファイルをキャッシュするために使用する,UBC に割り当てられたメモリの最大量を指定します。
vm_ubcseqstartpercent
属性 --
UBC がシーケンシャル・ファイル・アクセスを認識し,UBC LRU ページを流用してファイル用のページ要求を満たそうとし始めるしきい値を指定します。
この値は,物理メモリの割合で表わした UBC のサイズです。
注意
ubc_maxpercent
とubc_minpercent
の値が近い場合,ファイル・システムの性能が低下するおそれがあります。
チューニングするかどうかの判断
UBC に割り当てられているメモリ容量が不十分な場合,ファイル・システムの性能が低下することがあります。
UBC とプロセスがメモリを共有しているため,UBC 関連の属性値を変更すると,システムでページングが発生する原因になることがあります。
vmstat
コマンドの値を使用して,仮想メモリの統計情報を表示することができます。
この統計情報は,UBC 関連の属性の値を変更する必要があるかどうかを判断する際に役に立ちます。
vmstat
の出力に基づいて,UBC 関連の属性の値をいつ変更すれば良いかを,表 11-3に示します。
表 11-3: UBC 関連の属性の値を変更する時期
vmstat の出力にこの状況が頻繁に表示される場合 | 処置 |
ページングが行われているがページ・アウトがほとんど (またはまったく) ない |
|
ページングおよびスワッピング | ubc_maxpercent
属性の値を小さくする。 |
ページング | ubc_maxpercent
属性の値が
vm_ubseqstartpercent
属性の値より大きくなるようにし (省略時の設定),また
vm_ubcseqpercent
属性の値が参照されているファイルより大きくなるように指定して,システムが空きリストのページを使用しないで UBC のページを再使用するように強制する。 |
ページ・アウト | ubc_minpercent
属性の値を増やす |
vmstat
コマンドについての詳細は,12.3.1 項
を参照してください。
UBC メモリ割り当てについての詳細は,12.1.2.2 項
を参照してください。
この節で説明した UBC パラメータはすべて,システムをリブートすることなく変更できます。 システム属性の変更についての詳細は,第 3 章 を参照してください。
注意
ランダムな入出力を大量に実行するアプリケーションの性能は,UBC を大きくしても改善されません。 これは,ランダム入出力では,次にアクセスする位置が予測できないためです。
11.1.4 メタデータ・バッファ・キャッシュのチューニング
カーネルはブート時に,メモリの一部をメタデータ・バッファ・キャッシュ用に固定します。
UFS ファイルのメタデータ (スーパブロック,i ノード,間接ブロック,ディレクトリ・ブロック,シリンダ・グループ・サマリなど) は,メタデータ・バッファ・キャッシュにキャッシュされます。
メタデータが再使用されてメタデータ・バッファ・キャッシュ内にあった場合に,ファイル・システムの性能が向上します。
関連する属性
メタデータ・バッファ・キャッシュに関連する
vfs
サブシステム属性を,以下のリストに示します。
bufcache
--
カーネルがメタデータ・バッファ・キャッシュ用に固定するメモリのサイズを割合で指定します。
buffer_hash_size
-- メタデータ・バッファ・キャッシュのハッシュ・チェーン・テーブルのサイズをスロット数で指定します。
buffer_hash_size
属性と
bufcache
属性の値を変更したときには,システムのリブートが必要です。
カーネル・サブシステム属性の変更についての詳細は,第 3 章
を参照してください。
チューニングするかどうかの判断
キャッシュのミス率が高い (キャッシュのヒット率が低い) 場合は,bufcache
属性のサイズを増やすことを検討してください。
キャッシュのミス率が高いかどうかを判断するには,dbx print
コマンドを使用して
bio_stats
データ構造体を表示します。
ミス率 (ブロックのミス数を,ブロック・ミスとブロック・ヒットの和で割った値) が 3 パーセントを上回る場合は,bufcache
属性の値を増やすことを検討してください。
bio_stats
データ構造体の表示についての詳細は,11.3.2.3 項
を参照してください。
bufcache
属性の値を増やすと,プロセスおよび UBC で使用できるメモリの量が減少するので注意してください。
11.1.5 AdvFS アクセス構造体のチューニング
ブート時にシステムは,カーネルによって固定されていない物理メモリの一部を,AdvFS アクセス構造体用に予約します。 AdvFS はオープン・ファイルに関する情報と,オープンされていたが現在はクローズされているファイルに関する情報を,AdvFS 構造体にキャッシュします。 ファイル情報が再使用され,アクセス構造体の中にある場合に,ファイル・システムの性能が向上します。
AdvFS アクセス構造体は,カーネル構成およびシステムの負荷に応じて動的に割り当てと割り当て解除が行われます。
関連する属性
AdvfsAccessMaxPercent
-- AdvFS アクセス構造体に割り当てることができる,ページング可能メモリの最大容量を割合 (パーセント) で指定します。
AdvfsAccessMaxPercent
属性の値は,システムをリブートすることなく変更できます。
カーネル・サブシステム属性の変更についての詳細は,第 3 章
を参照してください。
チューニングするかどうかの判断
ユーザまたはアプリケーションが AdvFS ファイルを再使用する (たとえばプロキシ・サーバなど) 場合は,AdvfsAccessMaxPercent
属性の値を増やして,AdvFS アクセス構造体に割り当てるメモリを増やすことを検討してください。
AdvfsAccessMaxPercent
属性の値を増やすと,プロセスに使用できるメモリの量が減り,ページングとスワッピングが頻繁に発生することがあるので注意してください。
vmstat
コマンドを使用すると,仮想メモリの統計情報を表示して,ページングとスワッピングが頻繁に発生しているかどうかを調べることができます。
vmstat
コマンドについての詳細は,12.3.1 項
を参照してください。
次のような場合は,AdvFS アクセス構造体用に予約されているメモリの量を減らすことを検討してください。
AdvFS を使用していない場合
業務処理で同じファイルを何度もオープン,クローズ,再オープンしない場合
大容量メモリを使用している場合 (オープン・ファイルの数は,UBC メモリ使用量とプロセス・メモリ使用量ほどシステム・メモリの容量に比例して増えないため)。
ここでは,AdvFS (Advanced File System) のキューをチューニングする方法,AdvFS 構成のガイドライン,AdvFS の情報を表示するために使用できるコマンドについて説明します。
AdvFS の機能と,AdvFS のセットアップおよび管理についての詳細は,『AdvFS 管理ガイド』 を参照してください。
11.2.1 AdvFS の構成のガイドライン
ファイル・ドメイン内のボリュームでの入出力競合の量は,ファイルセットの性能に対して最も重要な要因となります。 これは,大規模で負荷の高いファイル・ドメインで発生することがあります。 ファイルセットのセットアップ方法を決めるには,まず次の項目を調べます。
頻繁にアクセスされるデータ
まれにしかアクセスされないデータ
特定タイプのデータ (一時的なデータやデータベースのデータなど)
特定のアクセス・パターンを持つデータ (作成,削除,読み取り,書き込みなど)
次に,上記の情報と次に示すガイドラインを用いてファイルセットとファイル・ドメインを構成します。
類似したタイプのファイルを含むファイルセットを同じファイル・ドメイン内に構成して,ディスクの断片化を減らし性能を改善します。
たとえば,cron
の出力,ニュース,メール,Web キャッシュ・サーバの出力などの小さな一時ファイルを,大規模なデータベース・ファイルと同じドメイン内に置かないようにしてください。
多数のファイルの作成または削除操作を実行するアプリケーションでは,複数のファイルセットを構成して,これらのファイルセットにファイルを分散させます。 これにより,個別のディレクトリ,ルート・タグ・ディレクトリ,クォータ・ファイル,フラグ・ファイルの競合は少なくなります。
アプリケーションが,異なる入出力アクセス・パターン (作成,削除,読み取り,書き込みパターンなど) で使用するファイルセットを同じファイル・ドメイン内に構成します。 これにより,入出力負荷のバランスがとれることがあります。
複数のファイルセットがあるマルチボリューム・ファイル・ドメイン内での入出力の競合を削減するには,複数のドメインを構成して,これらのドメインにファイルセットを分散させます。 これにより,各ボリュームとドメインではトランザクション・ログを使用するファイルセットの数が少なくなります。
小さいファイルが大量にあるファイルセットでは,vdump
および
vrestore
コマンドに悪影響を与えることがあります。
複数のファイルセットを使用すると,vdump
コマンドは各ファイルセットで同時に実行できるようになり,vrestore
コマンドでファイルセットを回復するために要する時間が短くなります。
表 11-4
に,その他の AdvFS 構成ガイドラインと,性能上の利点と欠点を示します。
AdvFS についての詳細は 『AdvFS 管理ガイド』 を参照してください。
表 11-4: AdvFS の構成のガイドライン
利点 | ガイドライン | 欠点 |
データの損失を防げる。 | LSM または RAID を用いて,RAID1 (ミラー・データ) または RAID5 でデータを格納する (11.2.1.1 項)。 | LSM または RAID が必要。 |
データの損失を防げる。 | 同期書き込みを強制するか,ファイルでのアトミック書き込みデータ・ロギングを有効にする (11.2.1.2 項)。 | ファイル・システムの性能が低下することがある。 |
データを 1 度だけ読み書きするアプリケーションの性能が向上する。 | 直接入出力を有効にする (11.2.1.3 項)。 | 同じデータにくり返しアクセスするアプリケーションの性能が低下する。 |
性能が改善される。 | AdvFS を使用してファイル・ドメイン内にファイルを分散させる (11.2.1.4 項)。 | なし。 |
性能が改善される。 | データをストライピングする (11.2.1.5 項)。 | AdvFS を使用している場合はなし。 または,LSM か RAID が必要。 |
性能が改善される。 | ファイル・ドメインの断片化を解消する (11.2.1.6 項)。 | なし。 |
性能が改善される。 | 入出力転送サイズを小さくする (11.2.1.7 項)。 | なし。 |
性能が改善される。 | トランザクション・ログを,高速なディスクまたは混雑していないディスクに移動する (11.2.1.8 項)。 | ディスクの増設が必要になる。 |
以降の項で,これらのガイドラインを詳しく説明します。
11.2.1.1 RAID1 または RAID5 を用いてデータを格納する
LSM またはハードウェア RAID を使用すると,RAID1 または RAID5 のデータ・ストレージを構成できます。
RAID1 の構成では,LSM やハードウェア RAID は,ファイル・ドメインまたはトランザクション・ログ・データのミラー (コピー) を複数のディスクに保存します。 ディスクに障害が発生すると,LSM やハードウェア RAID はミラーを用いてデータを使用可能にします。
RAID5 の構成では,LSM やハードウェア RAID はパリティ情報とデータを保存します。 ディスクに障害が発生すると,LSM やハードウェア RAID は,残ったディスク上のパリティ情報とデータを使用して,失われたデータを再構築します。
LSM についての詳細は 『Logical Storage Manager』 を参照してください。
ハードウェア RAID についての詳細は,ストレージ・デバイスのマニュアルを参照してください。
11.2.1.2 同期書き込み要求を強制するか,永続的なアトミック書き込みデータ・ロギングを有効にする
AdvFS は 8 KB 単位でディスクにデータを書き込みます。
特に指定しなければ,AdvFS の非同期書き込み要求は UBC にキャッシュされ,write
システム・コールは正常終了の値を返します。
データは後でディスクに書き込まれます (非同期)。
AdvFS では,書き込み中または書き込み直後にクラッシュが発生した場合,データのすべてまたは一部が実際にディスクに書き込まれたかどうかは保証されません。
たとえば,8 KB 単位のデータを 2 つ書き込む途中でシステムがクラッシュした場合,全書き込みの一部 (16 KB 未満) だけが正常に行われた可能性があります。
これにより,データが部分的に書き込まれ,データの不整合が発生することがあります。
AdvFS を構成して,指定されたファイルへの書き込み要求を強制的に同期的に実行し,write
システム・コールが正常な値を返す前に,確実にデータがディスクに書き込まれるようにすることができます。
指定したファイルへの永続的なアトミック書き込みデータ・ロギングを有効にすると,データはディスクに書き込まれる前にトランザクション・ログに書き込まれます。
write
システム・コールの途中または直後にシステムがクラッシュした場合,ログ・ファイル内のデータを使用して,回復時に
write
システム・コールを再構築できます。
1 つのファイルに対して,同期書き込みの強制と永続的なアトミック書き込みデータ・ロギングの両方を有効にすることはできません。
ただし,ファイルのアトミック書き込みデータ・ロギングを有効にして,そのファイルを
O_SYNC
オプション付きでオープンすることはできます。
このように指定すると,同期書き込みが行われる他,write
システム・コールから戻る前にクラッシュが発生した場合の部分的な書き込みも防止できます。
同期書き込み要求を強制するには,次のように入力します。
# chfile -l on filename
永続的なアトミック書き込みデータ・ロギングを有効にしたファイルは,mmap
システム・コールを使用してメモリにマップすることはできません。
また,直接入出力を有効にすることもできません (11.2.1.3 項
を参照)。
永続的なアトミック書き込みデータ・ロギングを有効にするには,次のように入力します。
# chfile -L on filename
永続的なアトミック書き込みデータ・ロギングが設定されたファイルは,書き込みが 8192 バイト以下で実行されたときのみ,アトミックに書き込まれます。 書き込みサイズが 8192 バイトより大きい場合には,8192 バイト以下の複数のセグメントに分割され,それぞれのセグメントがアトミックに書き込まれます。
NFS マウントされた AdvFS ファイルでアトミック書き込みデータ・ロギングを有効にする場合は,次の点を確かめてください。
NFS プロパティ・リスト・デーモン
proplistd
が NFS サーバ上で実行されており,proplist
オプション付きの
mount
コマンドで,ファイルセットがクライアントにマウントされていること。
ファイル内でのオフセットが 8 KB のページ境界に合っていること。 これは,NFS が 8 KB のページ境界に合わせて入出力を行うためです。 この場合,8 KB のページ境界から始まる 8192 バイトのセグメントだけが自動的に書き込まれます。
詳細は,
chfile
(8)11.2.1.3 直接入出力を有効にする
直接入出力を有効にすると,以前にアクセスしたデータを何度も再使用しないアプリケーションでの,ディスク入出力のスループットが大幅に向上します。 直接入出力を有効にする際に考慮が必要な点を,以下のリストに示します。
データは UBC にキャッシュされず,読み取りと書き込みは同期的に行われます。
非同期入出力 (AIO) 関数 (aio_read
および
aio_write
) を使用すると,要求の完了を待たずに 1 つ以上の同期直接入出力要求を発行することで,アプリケーションに非同期のような動作をさせることもできます。
直接入出力は任意のバイト・サイズの入出力要求をサポートしていますが,要求されたバイト転送がディスクのセクタ境界に合っていて,下位のディスク・セクタのサイズの偶数倍であれば,性能は最高になります。
データ・ロギング用にすでにオープンされているファイルや,メモリにマッピングされているファイルでは,直接入出力を有効にすることはできません。
F_GETCACHEPOLICY
引数を指定して
fcntl
システム・コールを呼び出すと,オープン・ファイルで直接入出力が有効になっているかどうかが判断できます。
特定のファイルに対して直接入出力を有効にするには,open
システム・コールを使用して,O_DIRECTIO
ファイル・アクセス・フラグをセットします。
直接入出力を指定してファイルをオープンすると,すべてのユーザがそのファイルをクローズするまでこのモードが有効になります。
詳細は,
fcntl
(2)open
(2)11.2.1.4 AdvFS を使用してファイルを分散させる
マルチボリューム・ドメイン内のファイルが均等に分散されていない場合,性能が低下することがあります。 マルチボリューム・ファイル・ドメイン内のボリュームに対して均等にスペースを分散させると,ドメイン内のボリュームの中で,使用中のスペースの割合のバランスをとることができます。 ファイルは,ドメイン内の各ボリュームで,使用中のスペースの割合ができるだけ均等になるまで,ボリューム間で移動できます
ファイルのバランシングが必要かどうかを判断するには,次のように入力します。
# showfdmn file_domain_name
次のような情報が表示されます。
Id Date Created LogPgs Version Domain Name 3437d34d.000ca710 Sun Oct 5 10:50:05 2001 512 3 usr_domain Vol 512-Blks Free % Used Cmode Rblks Wblks Vol Name 1L 1488716 549232 63% on 128 128 /dev/disk/dsk0g 2 262144 262000 0% on 128 128 /dev/disk/dsk4a --------- ------- ------ 1750860 811232 54%
% Used
フィールドには,現在,ファイルまたはメタデータ (ファイルセット・データ構造体) に割り当てられているボリューム・スペースの割合が表示されます。
上記の例では,usr_domain
ファイル・ドメインはバランスが取れていません。
ボリューム 1 には 63% の使用中のスペースがありますが,ボリューム 2 の使用中のスペースは 0% です (追加されたばかり)。
マルチボリューム・ファイル・ドメイン内の複数のボリュームに,使用中のスペースを均等に分散させるには,次のように入力します。
# balance file_domain_name
balance
コマンドは,ユーザおよびアプリケーションからは見えず,データの可用性には影響せず,ファイルの分割も行いません。
したがって,大きなファイルがあるファイル・ドメインでは,小さなファイルからなるファイル・ドメインほど均等にファイルをバランスさせることができないため,大きなファイルを,マルチボリューム・ファイル・ドメイン内の同じボリュームに手作業で移動することが必要になる場合があります。
ファイルを移動する必要があるかどうかを判断するには,次のように入力します。
# showfile -x file_name
次のような情報が表示されます。
Id Vol PgSz Pages XtntType Segs SegSz I/O Perf File 8.8002 1 16 11 simple ** ** async 18% src extentMap: 1 pageOff pageCnt vol volBlock blockCnt 0 1 1 187296 16 1 1 1 187328 16 2 1 1 187264 16 3 1 1 187184 16 4 1 1 187216 16 5 1 1 187312 16 6 1 1 187280 16 7 1 1 187248 16 8 1 1 187344 16 9 1 1 187200 16 10 1 1 187232 16 extentCnt: 11
上記の例のファイルは,別のボリュームに移動する候補としては良い例です。
エクステントが 11 個あり,Perf
フィールドに示されるように,性能効率が 18 パーセントだからです。
割合が高いほど,効率が良いということです。
ファイルをファイル・ドメイン内の別のボリュームに移動するには,次のように入力します。
# migrate [-p pageoffset] [-n pagecount] [-s volumeindex_from] \ [-d volumeindex_to] file_name
ファイルの移動元を指定することもできますし,ファイル・ドメイン内の最適の場所をシステムに選択させることもできます。 ファイル全体と特定のページのどちらでも,別のボリュームに移動させることができます。
ファイルを移動した後に
balance
ユーティリティを使用すると,ファイルが別のボリュームに移動されることがあるので,注意してください。
詳細は
showfdmn
(8)migrate
(8)balance
(8)11.2.1.5 データをストライピングする
AdvFS,LSM,ハードウェア RAID を使用すると,データのストライピング (分散) が実現できます。 ストライピングされたデータは,同じサイズのユニットに分割されてから 2 台以上のディスクに書き込まれ,データのストライプとして構成されたデータです。 2 台以上のユニットがあり,ディスクが複数の SCSI バス上にある場合,データは同時に書き込まれます。
384 KB のデータの書き込み要求が,6 個の 64 KB のデータ・ユニットに分割されて,2 つの完全なストライプとして 3 台のディスクに書き込まれる動作を,図 11-1
に示します。
図 11-1: データのストライピング
データをストライピングするときには,1 種類の方式のみを使用します。 場合によっては,複数のストライピング方式を用いて性能を改善できることがありますが,それは次のような場合に限られます。
ほとんどの入出力要求が大きい (1 MB 以上) 場合
異なるコントローラ上の複数の RAID セットに対してデータがストライピングされる場合
LSM や AdvFS のストライプ・サイズが,フル・ハードウェア RAID のストライプ・サイズの倍数である場合
AdvFS を用いたデータのストライピングについての詳細は
stripe
(8)11.2.1.6 ファイル・ドメインの断片化を解消する
エクステントは,AdvFS がファイルに割り当てる連続したディスク・スペースです。 エクステントは,1 つ以上の 8 KB ページからなります。 ファイルに記憶域が追加されると,エクステントとしてグループ化されます。 ファイル内のすべてのデータが連続したブロックに格納された場合,このファイルのファイル・エクステントは 1 個です。 ただし,ファイルが大きくなると,新しいデータを格納できるだけの連続ブロックがディスク上にない場合があります。 この場合,ファイルは連続していないブロック,また複数のファイル・エクステントに分散させなければなりません。
ファイルの入出力は,エクステントの数が少ないほど効率的になります。 ファイルが多数の小さなエクステントで構成されている場合,AdvFS はファイルを読み書きするために,より多くの入出力処理を必要とします。 ディスクが断片化されていると,エクステントが多くなり,ファイルにアクセスするときに多数のディスク・アドレスを調べなければならないため,読み書きの性能が低下します。
ファイル・ドメインの断片化情報を表示するには,次のように入力します。
# defragment -vn file_domain_name
次のような情報が表示されます。
defragment: Gathering data for 'staff_dmn' Current domain data: Extents: 263675 Files w/ extents: 152693 Avg exts per file w/exts: 1.73 Aggregate I/O perf: 70% Free space fragments: 85574 <100K <1M <10M >10M Free space: 34% 45% 19% 2% Fragments: 76197 8930 440 7
各ファイルのエクステントは少ない方が理想的です。
defragment
コマンドはデータの可用性には影響せず,ユーザおよびアプリケーションからは見えませんが,処理に時間がかかり,ディスク・スペースを必要とします。
ファイル・システムの動作が少ないときに定期的なファイル・システム保守作業の一環として,または断片化が多くなって問題が生じた場合に,defragment
コマンドを実行してください。
ファイル・ドメインに 8 KB 未満のファイルが含まれているか,ファイル・ドメインがメール・サーバで使用されているか,または読み取り専用である場合,断片化を解消しても性能はあまり向上しません。
また,showfile
コマンドを使用すると,ファイルの断片化を調べることができます。
詳細は
11.2.2.4 項と
defragment
(8)11.2.1.7 入出力転送サイズを小さくする
AdvFS は,デバイス・ドライバにとって最も効率の良いサイズで,ディスクに対するデータ転送を行います。 この値はデバイス・ドライバによって提示され,推奨転送サイズと呼ばれます。 AdvFS は推奨転送サイズを使用して以下の動作を実行します。
連続した小さい入出力転送を,推奨転送サイズの大きな入出力 1 つに統合します。 これにより,入出力要求の数が減少し,スループットが向上します。
シーケンシャルに読み取られるファイルに対して,アプリケーションが後で読み取ることを予測して,推奨転送サイズになるまで次のページを先取りまたは先読みします。
一般に,デバイス・ドライバが提供する入出力転送サイズは,最も効率的なサイズです。 ただし,場合によっては AdvFS の入出力サイズを小さくした方が良いことがあります。 たとえば,AdvFS ファイルセットで LSM ボリュームを使用している場合は,推奨転送サイズでは大きすぎることがあります。 この場合,読み取るファイル用にバッファが使用されるために,キャッシュが非常に希薄になることがあります。 このようなおそれがある場合,読み取り転送サイズを小さくすると,問題が緩和されることがあります。
mmap
ページ・フォールトの効率が悪いシステムや,メモリが制限されているシステムでは,読み取り転送サイズを制限して,先取りされるデータの量を制限します。
ただし,このようにすると,このディスクからの読み取りすべてで入出力の統合が制限されます。
ディスクに対する入出力転送サイズを表示するには,次のように入力します。
# chvol -l block_special_device_name domain
読み取り入出力転送サイズを変更するには,次のように入力します。
# chvol -r blocks block_special_device_name domain
書き込み入出力転送サイズを変更するには,次のように入力します。
# chvol -w blocks block_special_device_name domain
詳細は,
chvol
(8)
各デバイス・ドライバには,入出力転送サイズの最小値と最大値があります。
サポートされていない値を使用すると,デバイス・ドライバは自動的に値を制限して,サポートしている最大または最小の入出力転送サイズに変更します。
サポートされている入出力転送サイズについての詳細は,デバイス・ドライバのマニュアルを参照してください。
11.2.1.8 トランザクション・ログを移動する
AdvFS のトランザクション・ログは,高速なディスクとバス,またはアクセス頻度の低いディスクとバスに配置してください。 そうしないと,性能が低下することがあります。
ボリューム情報を表示するには,次のように入力します。
# showfdmn file_domain_name
次のような情報が表示されます。
Id Date Created LogPgs Domain Name 35ab99b6.000e65d2 Tue Jul 14 13:47:34 2002 512 staff_dmn Vol 512-Blks Free % Used Cmode Rblks Wblks Vol Name 3L 262144 154512 41% on 256 256 /dev/rz13a 4 786432 452656 42% on 256 256 /dev/rz13b ---------- ---------- ------ 1048576 607168 42%
showfdmn
コマンドの表示では,トランザクション・ログが置かれているボリュームの横に文字
L
が表示されます。
トランザクション・ログが置かれているディスクが低速または負荷が高い場合,次のようにします。
トランザクション・ログを別のディスクに移す。
switchlog
コマンドを使用してトランザクション・ログを移動します。
大きなマルチボリューム・ファイル・ドメインを,複数の小さなファイル・ドメインに分割する。 これにより,トランザクション・ログの入出力アクセスが複数のログに分散されます。
マルチボリューム・ドメインを複数の小さなドメインに分割するには,小さなドメインを作成してから,大きなドメインの一部を小さなドメインにコピーします。
AdvFS の
vdump
および
vrestore
コマンドを使用すると,大きなドメインで使用されていたディスクを,複数の小さなドメインの構築に使用できます。
詳細は,
showfdmn
(8)switchlog
(8)vdump
(8)vrestore
(8)11.2.2 AdvFS 統計情報のモニタリング
表 11-5
では,AdvFS 情報を表示するためのコマンドについて説明しています。
表 11-5: AdvFS 情報を表示するツール
ツール | 説明 | 参照先 |
|
AdvFS の性能の統計情報を表示する。 | |
|
ファイル・ドメイン内のディスクを表示する。 | |
|
AdvFS ファイル・ドメインとボリュームに関する情報を表示する。 | |
|
ファイル・ドメインに関する AdvFS ファイルセット情報を表示する。 | |
|
AdvFS ファイルセット内のファイルに関する情報を表示する。 |
以降の項では,これらのコマンドを詳しく説明します。
11.2.2.1 AdvFS の性能の統計情報を表示する
ファイル・ドメインについての詳細な情報 (UBC および namei キャッシュの使用状況,ファイルセットの vnode 動作,ロック,ビットファイル・メタデータ・テーブル (BMT) の統計情報,ボリュームの入出力性能など) を表示するには,advfsstat
コマンドを使用します。
次のコマンドを実行すると,ボリューム入出力キューの統計情報が表示されます。
# advfsstat -v 3 [-i number_of_seconds] file_domain
次のような情報が,1 ディスク・ブロック単位 (512 バイト) で表示されます。
rd wr rg arg wg awg blk ubcr flsh wlz sms rlz con dev 0 0 0 0 0 0 1M 0 10K 303K 51K 33K 33K 44K
-i
オプションを使用すると,特定の時間間隔 (秒単位) で情報を表示できます。
上記の例では,次のような内容が表示されています。
rd
(読み取り) および
wr
(書き込み) 要求
読み取り要求の数と書き込み要求の数を比較します。 読み取り要求は,読み取りが完了するまでブロックされますが,非同期書き込み要求では呼び出し元のスレッドがブロックされないため,マルチスレッドのスループットが向上します。
rg
および
arg
(統合された読み取り) と
wg
および
awg
(統合された書き込み)
統合された読み取りおよび書き込みの値は,デバイス・ドライバへの単一の入出力として統合された読み取りおよび書き込みの数を表します。 統合された読み取りおよび書き込みの数が,読み取りおよび書き込み数に比べて少ない場合,AdvFS は入出力を統合していない可能性があります。
blk
(ブロック・キュー),ubcr
(ubc リクエスト・キュー),flsh
(フラッシュ・キュー),wlz
(ウェイト・キュー),sms
(smooth sync キュー),rlz
(レディ・キュー),con
(コンソール・キュー),dev
(デバイス・キュー)。
AdvFS の入出力キューについての詳細は,11.2.3 項
を参照してください。
性能が低下し,flsh
キュー,blk
キュー,または
ubcr
キュー上の入出力要求の数が増加し続け,dev
キュー上の要求の数が一定している場合は,アプリケーションがこのデバイスの入出力に拘束されている可能性があります。
ドメインにディスクを追加するか,LSM またはハードウェア RAID でストライピングを行うと,この問題を解決できる可能性があります。
指定したドメインまたはファイルセットに関して,ファイルの作成,読み取り,書き込み,およびその他の動作の回数を表示するには,次のように入力します。
# advfsstat [-i number_of_seconds] -f 2 file_domain file_set
たとえば,次のように表示されます。
lkup crt geta read writ fsnc dsnc rm mv rdir mkd rmd link 0 0 0 0 0 0 0 0 0 0 0 0 0 4 0 10 0 0 0 0 2 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 24 8 51 0 9 0 0 3 0 0 4 0 0 1201 324 2985 0 601 0 0 300 0 0 0 0 0 1275 296 3225 0 655 0 0 281 0 0 0 0 0 1217 305 3014 0 596 0 0 317 0 0 0 0 0 1249 304 3166 0 643 0 0 292 0 0 0 0 0 1175 289 2985 0 601 0 0 299 0 0 0 0 0 779 148 1743 0 260 0 0 182 0 47 0 4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
詳細は,
advfsstat
(8)11.2.2.2 AdvFS ファイル・ドメイン内のディスクを表示する
AdvFS ドメインのすべてのデバイスと LSM ディスク・グループを検索する場合。
/etc/fdmns
ディレクトリ,/etc/fdmns
の下のディレクトリ・ドメイン,または
/etc/fdmns
の下のドメイン・ディレクトリからのリンクを削除したときに,/etc/fdmns
ディレクトリのすべてまたは一部を再構築する場合。
デバイスを移動してデバイス番号が変更された場合。
デバイス上,または LSM ディスク・グループ内の AdvFS ボリュームを表示するには,次のように入力します。
# advscan device | LSM_disk_group
次のような情報が表示されます。
Scanning disks dsk0 dsk5 Found domains: usr_domain Domain Id 2e09be37.0002eb40 Created Thu Jun 26 09:54:15 2002 Domain volumes 2 /etc/fdmns links 2 Actual partitions found: dsk0c dsk5c
失われたドメインをデバイス上に再度作成するには,次のように入力します。
# advscan -r device
次のような情報が表示されます。
Scanning disks dsk6 Found domains: *unknown* Domain Id 2f2421ba.0008c1c0 Created Mon Jan 20 13:38:02 2002 Domain volumes 1 /etc/fdmns links 0 Actual partitions found: dsk6a* *unknown* Domain Id 2f535f8c.000b6860 Created Tue Feb 25 09:38:20 2002 Domain volumes 1 /etc/fdmns links 0 Actual partitions found: dsk6b* Creating /etc/fdmns/domain_dsk6a/ linking dsk6a Creating /etc/fdmns/domain_dsk6b/ linking dsk6b
詳細は,
advscan
(8)11.2.2.3 AdvFS ファイル・ドメインを表示する
ファイル・ドメインに関する情報を表示するには,次のように入力します。 情報には,トランザクション・ログの作成日,サイズ,位置,ドメイン内の各ボリュームに関する情報 (サイズ,空きブロック数,同時に読み書きできるブロックの最大数,デバイス特殊ファイルなど) などがあります。
# showfdmn file_domain
次のような情報が表示されます。
Id Date Created LogPgs Version Domain Name 34f0ce64.0004f2e0 Wed Mar 17 15:19:48 2002 512 4 root_domain Vol 512-Blks Free % Used Cmode Rblks Wblks Vol Name 1L 262144 94896 64% on 256 256 /dev/disk/dsk0a
マルチボリューム・ドメインで
showfdmn
コマンドを使用すると,ボリューム全体のサイズ,空きブロックの総数,現在割り当てられているボリューム・スペース全体の割合も表示されます。
コマンドの出力についての詳細は,
showfdmn
(8)11.2.2.4 AdvFS ファイル情報を表示する
AdvFS ファイルセット内のファイル (およびディレクトリ) についての詳細情報を表示するには,次のように入力します。
# showfile filename...
または
# showfile *
*
を指定すると,現在の作業ディレクトリ内にある全ファイルの AdvFS 特性が表示されます。
次のような情報が表示されます。
Id Vol PgSz Pages XtntType Segs SegSz I/O Perf File 23c1.8001 1 16 1 simple ** ** ftx 100% OV 58ba.8004 1 16 1 simple ** ** ftx 100% TT_DB ** ** ** ** symlink ** ** ** ** adm 239f.8001 1 16 1 simple ** ** ftx 100% advfs ** ** ** ** symlink ** ** ** ** archive 9.8001 1 16 2 simple ** ** ftx 100% bin (index) ** ** ** ** symlink ** ** ** ** bsd ** ** ** ** symlink ** ** ** ** dict 288.8001 1 16 1 simple ** ** ftx 100% doc 28a.8001 1 16 1 simple ** ** ftx 100% dt ** ** ** ** symlink ** ** ** ** man 5ad4.8001 1 16 1 simple ** ** ftx 100% net ** ** ** ** symlink ** ** ** ** news 3e1.8001 1 16 1 simple ** ** ftx 100% opt ** ** ** ** symlink ** ** ** ** preserve ** ** ** ** advfs ** ** ** ** quota.group ** ** ** ** advfs ** ** ** ** quota.user b.8001 1 16 2 simple ** ** ftx 100% sbin (index) ** ** ** ** symlink ** ** ** ** sde 61d.8001 1 16 1 simple ** ** ftx 100% tcb ** ** ** ** symlink ** ** ** ** tmp ** ** ** ** symlink ** ** ** ** ucb 6df8.8001 1 16 1 simple ** ** ftx 100% users
このコマンドの出力についての詳細は,
showfile
(8)11.2.2.5 ファイル・ドメイン内の AdvFS ファイルセットを表示する
ファイルセット名,ファイルの総数,使用中のブロック数,クォータの状態,クローンの状態など,ファイル・ドメイン内のファイルセットに関する情報を表示するには,次のように入力します。
#
showfsets
file_domain
次のような情報が表示されます。
usr Id : 3d0f7cf8.000daec4.1.8001 Files : 30469, SLim= 0, HLim= 0 Blocks (512) : 1586588, SLim= 0, HLim= 0 Quota Status : user=off group=off Object Safety: off Fragging : on DMAPI : off
上記の例は,dmn1
というファイル・ドメインに,ファイルセットが 1 つとクローン・ファイルセットが 1 つあることを示しています。
詳細は
showfsets
(8)11.2.3 AdvFS キューのチューニング
各 AdvFS ボリュームでは,入出力要求は次のいずれかのキューに送られます。
ブロック・キュー/UBC キュー/フラッシュ・キュー
ブロック・キュー,UBC キュー,およびフラッシュ・キューは,読み取りおよび同期書き込み要求をキャッシュするキューです。 同期書き込み要求では,ディスクへの書き込みが完了した後に,アプリケーションが続行可能になります。
ブロック・キューは,主に読み取りおよびカーネルの同期書き込みに使用されます。
UBC リクエスト・キューは,ページをディスクへフラッシュする UBC リクエストを処理するために使用されます。
フラッシュ・キューは,主にバッファの書き込み要求に使用されます。
これには
fsync()
,sync()
,同期書き込みがあります。
ブロック・キューと UBC リクエスト・キューのバッファはフラッシュ・キューよりも優先順位が少し高いので,カーネルの要求は迅速に処理され,ディスクへの書き込みを待っているバッファが多数ある場合でもブロックされません。
ブロック・キュー,UBC リクエスト・キュー,またはフラッシュ・キューのバッファにあるデータの読み取りや変更を行うプロセスは,データがディスクに書き込まれるまで待たなければなりません。 最終的にデバイス・キューに移動されるまでは,いつでも変更が可能であるレイジー・キューのバッファとは,この点が異なります。
レイジー・キュー
レイジー・キューは,非同期の書き込み要求をキャッシュする論理的なキューの並びです。 非同期入出力要求は,レイジー・キューに入れられるとタイム・スタンプが割り当てられます。 このタイム・スタンプは,要求をまとめて大きな入出力に統合して,バッファを定期的にディスクにフラッシュするために使用します。 プロセスは,レイジー・キューにあるバッファ内のデータをいつでも変更して,新たに入出力が発生しないようにすることができます。 レイジー・キュー内のキューについては,図 11-2 の後で説明しています。
これらの 4 つのキュー (ブロック,UBC リクエスト,フラッシュ,レイジー) では,バッファがデバイス・キューに移されます。 バッファがデバイス・キューに移されるときに,論理的に連続した入出力は,より大きな入出力に統合されます。 これにより,実行しなければならない実際の入出力の数は少なくなります。 デバイス・キュー上のバッファは,入出力が完了するまで変更できません。
バッファをデバイス・キューに移すアルゴリズムでは,ブロック・キュー,UBC リクエスト・キュー,フラッシュ・キューの順でバッファをキューから取り出します。 また,この 3 つはいずれもレイジー・キューより優先されます。 デバイス・キューのサイズは,デバイスおよびドライバのリソースによって制限されます。 デバイス・キューにロードするアルゴリズムでは,ドライバからのフィードバックによって,デバイス・キューがいつ満杯になったか分かります。 この時点でデバイスは飽和状態になっているため,これ以上バッファをデバイス・キューへ移動しても,デバイスのスループットが低下するだけです。 同期入出力動作にかかる時間は,最終的には,デバイス・キューのサイズと,混み具合によって決まります。
図 11-2
は,AdvFS 入出力キューでの同期および非同期入出力要求の移動の状況を示しています。
図 11-2: AdvFS の入出力キュー
AdvFS のレイジー・キューについて,次に詳しく説明します。
ウェイト・キュー -- AdvFS トランザクション・ログの書き込み完了を待っている非同期入出力要求は,最初にウェイト・キューに入ります。 各ファイル・ドメインには,ファイル・ドメイン内の全ファイルセットのファイルセット動作を追跡し,クラッシュが発生しても AdvFS メタデータの整合性を確保できるようにするトランザクション・ログがあります。
AdvFS は,先書きロギングを使用します。 先書きロギングを使用する場合,メタデータの変更時には,実際のメタデータが書き込まれる前にトランザクション・ログの書き込みが完了していなければなりません。 これにより,AdvFS はいつでもトランザクション・ログを使用して,ファイル・システムのメタデータを矛盾のない状態にすることができます。 トランザクション・ログの書き込みが完了すると,入出力要求はウェイト・キューから smooth sync キューに移動できます。
smooth sync キュー -- 非同期入出力要求は,特に指定しなければ最低 30 秒間 smooth sync キューにとどまります。 指定した時間の間,smooth sync キューに要求がとどまるようにすると,入出力の集中を防止でき,キャッシュのヒット率が向上し,要求の統合が進みます。 要求は,smooth sync キューの中で一定期間を過ぎるとレディ・キューに移されます。
レディ・キュー -- 非同期入出力は,レディ・キューの中でソートされます。 キューが指定されたサイズになると,要求はコンソール・キューに移されます。
関連する属性
次のリストでは,AdvFS キューに関連する
vfs
サブシステム属性について説明します。
smoothsync_age
-- 変更されたページが,smoothsync メカニズムでディスクにフラッシュできる状態になるまでに待たされる時間を秒数で指定します。
smoothsync_age
属性は,システムがマルチユーザ・モードでブートされると有効になり,システムがマルチユーザ・モードからシングルユーザ・モードに切り替わったときに無効になります。
smoothsync_age
属性の値を永続的に変更するには,/etc/inittab
ファイルの以下の行を編集します。
smsync:23:wait:/sbin/sysconfig -r vfs smoothsync_age=30 > /dev/null 2>&1 smsyncS:Ss:wait:/sbin/sysconfig -r vfs smoothsync_age=0 > /dev/null 2>&1
smsync2
マウント・オプションを使用すると,代替の smoothsync ポリシを指定して,さらに正味の入出力負荷を軽減することができます。
省略時のポリシは,ページへの変更が継続されているかどうかにかかわらず,smoothsync_age
で指定した時間が経過したダーティ・ページをフラッシュすることです。
smsync2
マウント・オプションを使用してファイル・システムをマウントした場合,非メモリ・マップ・モードの変更ページは,smoothsync_age
で指定された時間の間ダーティでかつアイドルでなければ,ディスクには書き込まれません。
メモリ・マップ・モードの AdvFS ファイルは,smoothsync_age
に従ってフラッシュされない可能性があることに注意してください。
AdvfsSyncMmapPages
--
mmap
ページのフラッシュを独自に管理するアプリケーションに対して,smoothsync を無効にするかどうかを指定します。
詳細は,
mmap
(2)msync
(2)
AdvfsReadyQLim
-- レディ・キューのサイズを指定します。
AdvfsSyncMmapPages
属性,smoothsync_age
属性,および
AdvfsReadyQLim
属性の値は,システムをリブートすることなく変更できます。
カーネル・サブシステム属性の変更については,第 3 章
を参照してください。
チューニングするかどうかの判断
データを再使用する場合は,次の値を増やすことを検討してください。
入出力要求が smoothsync キューにとどまる時間を長くして,キャッシュのヒット率を高めます。 ただし,このようにすると,システム・クラッシュが起きたときにデータが失われる可能性が高くなります。
advfsstat -S
コマンドを使用して,AdvFS smoothsync キューのキャッシュ統計情報を表示します。
レディ・キューの大きさを大きくして,入出力要求が単一の大きな入出力に統合される可能性を高くして,キャッシュのヒット率を高めます。 ただし,smoothsync が有効なときにはあまり影響がなく,受け付けた要求をレディ・キュー内でソートするオーバヘッドが増えることがあります。
ここでは,UFS 構成とチューニングのガイドライン,および UFS 情報を表示するためのコマンドについて説明します。
11.3.1 UFS の構成のガイドライン
表 11-6
では,UFS の構成のガイドラインと,性能上の利点と欠点について説明します。
表 11-6: UFS の構成のガイドライン
利点 | ガイドライン | 欠点 |
小さいファイルの性能が改善される。 | ファイル・システムのフラグメント・サイズをブロック・サイズと等しくする (11.3.1.1 項)。 |
小さいファイルでは,ディスク・スペースが浪費される。 |
大規模なファイルの性能が改善される。 | 省略時のファイル・システム・フラグメント・サイズとして 1 KB を使用する (11.3.1.1 項)。 |
大規模なファイルでは,オーバヘッドが増加する。 |
ディスク・スペースが解放され,大規模なファイルの性能が改善される。 | ファイル・システムの i ノードの密度を低くする (11.3.1.2 項)。 |
作成できるファイルの数が少なくなる。 |
先読みキャッシュを備えていないディスクで性能が改善される。 | 回転遅延時間を設定する (11.3.1.3 項)。 |
なし。 |
ディスクの入出力動作の回数が少なくなる。 | クラスタとして結合するブロックの数を増やす (11.3.1.4 項)。 |
なし。 |
性能が改善される。 | メモリ・ファイル・システム (MFS) を使用する (11.3.1.5 項)。 |
揮発性のキャッシュであるため,データの完全性が保証されない。 |
ディスク・スペースの使用量を制御できる。 | ディスク・クォータを使用する (11.3.1.6 項)。 |
リブート時間が少し長くなることがある。 |
より多くのファイル・システムをマウントできる。 | UFS および MFS のマウントの最大数を大きくする (11.3.1.7 項)。 |
追加メモリ・リソースが必要。 |
以降の項で,これらのガイドラインを詳しく説明します。
11.3.1.1 ファイル・システムのフラグメント・サイズとブロック・サイズを変更する
UFS ファイル・システムのブロック・サイズは 8 KB です。
省略時のフラグメント・サイズは 1 KB です。
newfs
コマンドでは,作成時のフラグメント・サイズを,1024 KB,2048 KB,4096 KB,8192 KB のいずれかにできます。
省略時のフラグメント・サイズでは,ディスク・スペースが効率的に使用されますが,96 KB 未満のファイルではオーバヘッドが増加します。 ファイル・システム内の平均的なファイルが 96 KB より小さい場合,ファイル・システムのフラグメント・サイズを省略時のブロック・サイズ (8 KB) と同じにすると,ディスクのアクセス速度が改善され,システムのオーバヘッドが小さくなる可能性があります。
詳細は
newfs
(8)11.3.1.2 i ノードの密度を低くする
i ノードには,ファイル・システム内の各ファイルの情報が記述されています。 ファイル・システムの最大ファイル数は,i ノードの数とファイル・システムのサイズによって決まります。 システムは,ファイル・システム内のデータ・スペース 4 KB (4096 バイト) ごとに,i ノードを 1 つ作成します。
ファイル・システムに大きなファイルが多数含まれ,4 KB のスペースの単位ではファイルを作成しないことが分かっている場合は,ファイル・システム上の i ノードの密度を低くすることができます。 これによりファイル・データ用にディスク・スペースが解放されますが,作成できるファイルの数は少なくなります。
i ノードの密度を低くするには,newfs -i
コマンドを使用してファイル・システムを作成するときに,各 i ノードに割り当てられるディスク・スペースの量を指定します。
詳細は,
newfs
(8)11.3.1.3 回転遅延時間を設定する
UFS の
rotdelay
パラメータは,転送完了の割り込みを処理して同じディスク上で新しい転送を開始するためにかかる時間をミリ秒単位で指定します。
この値は,ファイル内の連続したブロックの間の回転スペースの量を判断する際に使用します。
特に指定しなければ,rotdelay
パラメータは 0 に設定され,ブロックを連続して割り当てることができます。
この設定は,先読みキャッシュを備えていないディスクで
rotdelay
を設定する場合に役立ちます。
キャッシュを備えているディスクでは,rotdelay
を 0 に設定します。
rotdelay
の値を変更するには,tunefs
コマンドまたは
newfs
コマンドを使用します。
詳細は,
newfs
(8)tunefs
(8)11.3.1.4 クラスタとして結合するブロックの数を増やす
UFS の
maxcontig
パラメータの値は,単一のクラスタ (ファイル・ブロック・グループ) として結合できるブロックの数を指定します。
maxcontig
の省略時の値は 8 です。
ファイル・システムは,maxcontig
の値にブロック・サイズ (8 KB) を掛けた値のサイズで,入出力動作を実行します。
複数のバッファをチェーンして 1 回で転送するデバイス・ドライバでは,maxcontig
の値を最大チェーン数として使用しなければなりません。
チェーンすることにより,ディスクの入出力動作の回数が少なくなります。
maxcontig
の値を変更するには,tunefs
コマンドまたは
newfs
コマンドを使用します。
詳細は,
newfs
(8)tunefs
(8)11.3.1.5 MFS を使用する
メモリ・ファイル・システム (MFS) は,メモリ内のみに存在する UFS ファイル・システムです。 永続的なデータやファイル構造がディスクに書き込まれることはありません。 MFS を使用すると,読み書きの性能を改善できます。 ただし,MFS は揮発性のキャッシュなので,MFS の内容は,リブートや,アンマウント動作,電源障害の後には失われます。
ディスクにデータが書き込まれないため,MFS は非常に高速なファイル・システムであり,作成後にファイル・システムにロードされる一時ファイルや読み取り専用のファイルの格納に使用できます。 たとえば,ソフトウェアの構築 (障害の発生時には再起動し直されるもの) を行っている場合は,構築中に作成される一時ファイルのキャッシュに MFS を使用すると,構築時間を短縮できます。
詳細は,
mfs
(8)11.3.1.6 UFS のディスク・クォータを使用する
UFS のディスク・クォータ (UFS のファイル・システム・クォータ) を設定すると,ユーザ・アカウントおよびグループに対して,UFS ファイル・システムの限界値を指定できます。 ファイル・システムにクォータを適用すると,ユーザ・アカウントまたはユーザ・グループに割り当てることのできるブロックおよび i ノード (ファイル) の数の限界値を設定できます。 各ファイル・システム上のユーザまたはユーザ・グループそれぞれに対して,別のクォータを設定できます。
ホーム・ディレクトリが配置されているファイル・システムにクォータを設定してください。
これは,ホーム・ディレクトリが置かれているファイル・システムのサイズは,他のファイル・システムより大きくなるためです。
/tmp
ファイル・システムにはクォータを設定しないでください。
AdvFS クォータとは異なり,UFS クォータを使用すると,リブート時間が少し長くなることがあります。
AdvFS クォータについては,『AdvFS 管理ガイド』を参照してください。
UFS クォータについては,『システム管理ガイド』を参照してください。
11.3.1.7 UFS および MFS のマウントの数を増やす
マウント構造体は,マウント要求時に動的に割り当てられ,その後,アンマウント要求時に割り当て解除されます。
関連する属性
max_ufs_mounts
属性は,システム上の UFS および MFS のマウントの最大数を指定します。
値: 0 〜 2,147,483,647
省略時の値: 1000 (ファイル・システム・マウント)
max_ufs_mounts
属性は,システムをリブートすることなく変更できます。
カーネル・サブシステム属性の変更についての詳細は,第 3 章
を参照してください。
チューニングするかどうかの判断
システムのマウント数が省略時の限界値である 1000 マウントよりも多い場合は,UFS および MFS マウントを増やしてください。
UFS および MFS マウントの最大数を増やすと,マウントできるファイル・システムの数が多くなります。
ただし,最大マウント数を多くすると,追加のマウント用にメモリ・リソースが必要になります。
11.3.2 UFS 統計情報のモニタリング
表 11-7
では,UFS の情報を表示できるコマンドについて説明します。
表 11-7: UFS 情報を表示するツール
ツール | 説明 | 参照先 |
|
UFS 情報を表示する。 | |
|
UFS クラスタの統計情報を表示する。 | |
|
メタデータ・バッファ・キャッシュの統計情報を表示する。 |
ファイル・システムを指定して UFS 情報 (スーパブロック,シリンダ・グループ情報など) を表示するには,次のように入力します。
# dumpfs filesystem | /devices/disk/device_name
次のような情報が表示されます。
magic 11954 format dynamic time Tue Sep 14 15:46:52 2002 nbfree 21490 ndir 9 nifree 99541 nffree 60 ncg 65 ncyl 1027 size 409600 blocks 396062 bsize 8192 shift 13 mask 0xffffe000 fsize 1024 shift 10 mask 0xfffffc00 frag 8 shift 3 fsbtodb 1 cpg 16 bpg 798 fpg 6384 ipg 1536 minfree 10% optim time maxcontig 8 maxbpg 2048 rotdelay 0ms headswitch 0us trackseek 0us rps 60
先頭の数行には,チューニングに関連する情報が含まれています。 特に重要なフィールドを,次に示します。
bsize
--
ファイル・システムの,バイト単位のブロック・サイズ (8 KB)。
fsize
--
ファイル・システムの,バイト単位のフラグメント・サイズ。
入出力の性能を最適化するために,フラグメント・サイズを変更することができます。
minfree
--
通常のユーザが使用できないスペースの割合 (最小空きスペースのしきい値)。
maxcontig
--
回転遅延を強制しないで,連続して配置されるブロックの最大数。
つまり,結合されて単一の読み取り要求になるブロックの数。
maxbpg
--
1 つのファイルに,1 つのシリンダ・グループから割り当てることができるブロック数の最大値。
この数を超えると,強制的に他のシリンダ・グループからの割り当てが開始されます。
maxbpg
の値を大きくすると,大規模なファイルの性能が改善されます。
rotdelay
--
転送完了の割り込みを処理し,同じディスク上で新しい転送を開始するためにかかる時間の予測値 (ミリ秒)。
ファイル内の連続するブロック間に,どれだけの回転遅延スペースを置くかを決定するために使用されます。
rotdelay
が 0 の場合,ブロックは連続して割り当てられます。
システムでクラスタの読み書き転送がどのように実行されているかを表示するには,dbx print
コマンドを使用して
ufs_clusterstats
データ構造体を調べます。
以下に例を示します。
# /usr/ucb/dbx -k /vmunix /dev/mem (dbx) print ufs_clusterstats
次のような情報が表示されます。
struct { full_cluster_transfers = 3130 part_cluster_transfers = 9786 non_cluster_transfers = 16833 sum_cluster_transfers = { [0] 0 [1] 24644 [2] 1128 [3] 463 [4] 202 [5] 55 [6] 117 [7] 36 [8] 123 [9] 0 . . . [33] } } (dbx)
上記の例では,単一ブロックの転送が 24644 回,2 ブロックの転送が 1128 回,3 ブロックの転送が 463 回,となっています。
dbx print
コマンドを使用すると,ufs_clusterstats_read
と
ufs_clusterstats_write
データ構造体を指定して,クラスタの読み取りと書き込みを別々に調べることもできます。
11.3.2.3 メタデータ・バッファ・キャッシュを表示する
メタデータ・バッファ・キャッシュの統計情報 (スーパブロック,i ノード,間接ブロック,ディレクトリ・ブロック,シリンダ・グループ要約) を表示するには,dbx print
コマンドを使用して,bio_stats
データ構造体を調べます。
以下に例を示します。
# /usr/ucb/dbx -k /vmunix /dev/mem (dbx) print bio_stats
次のような情報が表示されます。
struct { getblk_hits = 4590388 getblk_misses = 17569 getblk_research = 0 getblk_dupbuf = 0 getnewbuf_calls = 17590 getnewbuf_buflocked = 0 vflushbuf_lockskips = 0 mntflushbuf_misses = 0 mntinvalbuf_misses = 0 vinvalbuf_misses = 0 allocbuf_buflocked = 0 ufssync_misses = 0 }
ブロック・ミスの数 (getblk_misses
) をブロック・ミスとブロック・ヒット (getblk_hits
) の和で割った値が,3 パーセントを超えないようにしてください。
ブロック・ミスの値が大きい場合は,bufcache
属性の値を大きくしてください。
bufcache
属性の値を増やす方法についての詳細は,11.1.4 項
を参照してください。
11.3.3 UFS の性能のチューニング
表 11-8
では,UFS のチューニング・ガイドラインと,性能上の利点と欠点について説明します。
表 11-8: UFS のチューニング・ガイドライン
利点 | ガイドライン | 欠点 |
性能が改善される。 | 非同期 UFS 入出力要求に対して UFS smoothsync および入出力スロットリングを調整する (11.3.3.1 項)。 |
なし。 |
CPU 時間が解放され,入出力動作の回数が少なくなる。 | UFS クラスタの書き込みを遅らせる(11.3.3.2 項)。 |
入出力スロットリングを使用しない場合,バッファのフラッシュ時に,リアルタイム処理の性能が低下することがある。 |
ディスクの入出力動作の回数が少なくなる。 | クラスタ用に結合したブロックの数を増やす (11.3.3.3 項)。 |
バッファ・データに必要なメモリ量が多くなることがある。 |
読み書きの性能が改善される。 | ファイル・システムの断片化を解消する (11.3.3.4 項)。 |
ダウン時間が必要。 |
以降の項で,これらのガイドラインを詳しく説明します。
11.3.3.1 UFS Smooth Sync と入出力スロットリングを調整する
UFS では,smoothsync と入出力スロットリングを用いて UFS の性能を改善し,システムの入出力負荷が重過ぎてシステムが停止状態になるのを最小限に抑えます。
smoothsync 機能を使用すると,ダーティ・ページは,指定された時間が経過してからディスクに書き出されます。
これにより,頻繁に変更されるページがキャッシュ内で見つかることが多くなり,入出力の負荷が軽減されます。
また,ダーティ・ページが大量にデバイス・キューにロックされたために発生するスパイクが,最小限に抑えられます。
これは,update
デーモンにフラッシュされた場合とは逆に,十分な時間が経過した後にページがデバイス・キューに入れられるためです。
さらに,入出力スロットリングはダーティ・ページをデバイス・キューにロックする場合にも対応できます。
これは,任意の時点でデバイス・キューに入れることができる,遅延入出力要求の数を強制的に制限します。
これにより,新しいプログラムのメモリへの読み込みやロードなどで,デバイス・キューに追加された同期要求に対する応答性が良くなります。
また,ページは,デバイス・キューに置かれるまで使用できるため,ダーティ・バッファの参照でのプロセスの遅延の頻度や時間が減少します。
関連する属性
smoothsync とスロットリングに影響する
vfs
サブシステム属性は,次のとおりです。
smoothsync_age
--
変更ページが smoothsync メカニズムによってディスクにフラッシュできるようになるまでの時間を秒数で指定します。
update
デーモンによって制御されるようになります。
チューニングするかどうかの判断
この値を大きくすると,システムがクラッシュした場合にデータが失われる可能性も高くなりますが,ダーティ・ページがキャッシュにとどまる時間が長くなるため,正味の入出力負荷は軽減されます (性能が改善されます)。
smoothsync_age
属性は,システムがマルチユーザ・モードでブートされたときに有効となり,システムがマルチユーザからシングルユーザ・モードに切り替ったときに無効になります。
smoothsync_age
属性の値を変更するには,/etc/inittab
ファイルの以下の行を編集します。
smsync:23:wait:/sbin/sysconfig -r vfs smoothsync_age=30 > /dev/null 2>&1 smsyncS:Ss:wait:/sbin/sysconfig -r vfs smoothsync_age=0 > /dev/null 2>&1
smsync2
マウント・オプションを使用すると,代替の smoothsync ポリシを指定して,さらに正味の入出力負荷を軽減することができます。
省略時のポリシは,ページへの変更が継続されているかどうかにかかわらず,smoothsync_age
で指定した時間が経過したダーティ・ページをフラッシュすることです。
smsync2
マウント・オプションを使用して UFS をマウントした場合,変更ページは,smoothsync_age
で指定された時間の間ダーティでかつアイドルでなければ,ディスクには書き込まれません。
メモリ・マップされたページでは,smsync2
の設定とは無関係に,常にこの省略時のポリシが使用されるので注意してください。
io_throttle_shift
--
入出力デバイス・キューに同時に入れることができる遅延 UFS 入出力要求の最大数を制限するための値を指定します。
io_throttle_shift
属性は,マウント・オプションの
throttle
を使ってマウントしたファイル・システムだけに適用されます。
入出力デバイス・キュー上の要求の数が増えるほど,要求を処理してページとデバイスが使用できるようになるまでの時間が長くなります。
入出力デバイス・キューに同時に入れることができる遅延入出力要求の数は,io_throttle_shift
属性を設定することで絞る (制御する) ことができます。
算出されたスロットルの値は,io_throttle_shift
属性の値と,算出されたデバイス入出力完了レートに基づいています。
入出力デバイス・キューの処理に必要な時間は,スロットルの値に比例します。
io_throttle_shift
属性の値とデバイス・キューの処理に必要な時間の対応は,次のようになります。
io_throttle_shift 属性の値 | デバイス・キューの処理に要する時間 (秒数) |
-4 | 0.0625 |
-3 | 0.125 |
-2 | 0.25 |
-1 | 0.5 |
0 | 1 |
1 | 2 |
2 | 4 |
3 | 8 |
4 | 16 |
入出力デバイスへのアクセス遅延が特に問題となる環境では,io_throttle_shift
属性の値を減らすことを検討してください。
io_maxmzthruput
--
入出力スループットを最大化するかどうか,またはダーティ・ページの可用性を最大化するかどうかを指定します。
入出力スループットを最大化すると,デバイスのビジー状態が続くように積極的に動きますが,それは
io_throttle_shift
属性で指定した値の範囲にとどまります。
ダーティ・ページの可用性を最大化すると,ダーティ・ページを待つための停止時間が削減されます。
値: 0 (無効) または 1 (有効)
省略時の値: 1 (有効)。
ただし,io_throttle_maxmzthruput
属性は,throttle
マウント・オプションを用いてマウントしたファイル・システムにのみ適用されます。
チューニングするかどうかの判断
頻繁に使用されるダーティ・ページへのアクセス遅延が問題となる環境や,入出力が少数の入出力多用アプリケーションに限られており,全体的な性能を良くするには,入出力デバイスをビジー状態に保つことよりも,特定のページ・セットへのアクセスが重要になるような環境では,io_maxmzthruput
属性を無効にすることを検討してください。
smoothsync_age
,io_throttle_static
,io_throttle_maxmzthruput
の各属性は,システムをリブートすることなく変更できます。
11.3.3.2 UFS クラスタの書き込みを遅らせる
特に指定しなければ,UFS ページのクラスタには非同期書き込みが行われます。
他の変更されたデータとメタデータ・ページの書き込みと同じように,UFS ページのクラスタが遅れて書き込まれるように構成することもできます。
関連する属性
delay_wbuffers
--
UFS ページのクラスタの書き込みが非同期で行われるか,または遅延されるかを指定します。
delay_wbuffers_percent
属性の値に達すると,クラスタは
delay_wbuffers
属性の値にかかわらず非同期で書き込まれます。
以前に書き込んだページに頻繁に書き込みを行うアプリケーションの場合は,UFS ページのクラスタの書き込みを遅らせてください。 これにより,入出力要求の総数が少なくなります。 ただし,入出力スロットリングを使用していない場合は,同期の際にシステムの入出力負荷が重くなるため,リアルタイム処理の性能に悪影響を与えることがあります。
UFS ページのクラスタの書き込みを遅らせるには,dbx patch
コマンドを使用して
delay_wbuffers
カーネル変数を 1 (有効) に設定します。
dbx
の使用についての詳細は,3.2 節
を参照してください。
11.3.3.3 クラスタ内のブロックの数を増やす
UFS は連続するブロックを連結してクラスタとし,入出力動作を減らします。
クラスタ内のブロックの数は指定できます。
関連する属性
cluster_maxcontig
--
単一の入出力動作として連結されるブロックの数を指定します。
特定のファイル・システムの回転遅延時間の値が 0 (省略時の値) の場合,UFS はブロック数が
n
個までのクラスタを作成しようとします。
ここで,n
は,cluster_maxcontig
属性の値,デバイス・ジオメトリの値のうち,小さい方になります。
特定のファイル・システムの回転遅延時間が 0 以外の値であれば,n
は,cluster_maxcontig
属性の値,デバイス・ジオメトリの値,maxcontig
ファイル・システム属性の値のうち,小さい方の値になります。
チューニングするかどうかの判断
アプリケーションがサイズの大きなクラスタを使用できる場合は,クラスタとして連結するブロック数を増やします。
newfs
コマンドを使用すると,ファイル・システムの回転遅延時間と
maxcontig
属性の値を設定できます。
dbx
コマンドを使用すると,cluster_maxcontig
属性の値を設定できます。
11.3.3.4 ファイル・システムの断片化を解消する
連続していないファイル・エクステントでファイルが構成されている場合,そのファイルは断片化していると考えられます。 断片化の度合いが大きいファイルでは,ファイルのアクセスに必要な入出力動作が多くなるため,UFS の読み書きの性能が低下します。
作業のタイミング
UFS ファイル・システムの断片化を解消すると,ファイル・システムの性能が改善されます。 ただし,断片化の解消には時間がかかります。
ファイル・システム内のファイルが断片化しているかどうかは,システムのクラスタ化の効率を調べることで判断できます。
判断するには,dbx print
コマンドを使用して,ufs_clusterstats
データ構造体を調べます。
詳細は,11.3.2.2 項を参照してください。
UFS ブロックをクラスタ化すると,通常は効率がよくなります。 UFS クラスタ化のカーネル構造体で,クラスタ化の効率が良くないという数値が示された場合は,ファイル・システム内のファイルが断片化している可能性があります。
推奨手順
UFS ファイル・システムの断片化を解消するには,次の手順に従います。
テープまたは他のパーティションに,ファイル・システムをバックアップします。
同じパーティションまたは別のパーティションに,新しいファイル・システムを作成します。
ファイル・システムをリストアします。
データのバックアップおよびリストアと,UFS ファイル・システムの作成については,『システム管理ガイド』を参照してください。
11.4 NFS のチューニング
ネットワーク・ファイル・システム (NFS) は,ユニファイド・バッファ・キャッシュ (UBC) を,仮想メモリ・サブシステムおよびローカル・ファイル・サブシステムと共有します。 NFS は,ネットワークに過度の負荷をかけることがあります。 NFS の性能が良くない場合は大半が,ネットワーク・インフラストラクチャの問題です。 NFS クライアントの再送メッセージの数が多くないか,ネットワークの入出力エラーがないか,負荷に耐えられないルータがないかを調べてください。
ネットワーク上でパケットの紛失があると,NFS の性能が大幅に低下します。 パケットの紛失は,サーバの輻輳,送信中のパケットの破損 (電気的接続の問題や,ノイズの多い環境,ノイズの多いイーサネット・インタフェースが原因),転送処理の放棄が早過ぎるルータが原因で発生します。
ネットワーク・ファイル・システムのチューニング方法は,第 5 章を参照してください。