rpcmod モジュールのパラメータ

この節では、rpcmod モジュールの NFS パラメータについて説明します。

rpcmod:clnt_max_conns

備考欄

個々のN FS サーバーと通信するときに、NFS クライアントが使用する TCP 接続の数を制御します。1 つの接続で RPC を多重化できるように、カーネル RPC が構築されます。しかし、必要な場合には複数の接続を使用できます。

データ型

整数 (32 ビット)

デフォルト

1

範囲

1 から 2³¹ - 1

単位

接続

動的か

はい

検査

なし

どのような場合に変更するか

一般には、1 つの接続だけでネットワーク帯域幅全体を使いきることができます。しかし、ネットワークが提供する帯域幅を TCP が 1 つのストリームだけで利用できない場合は、複数の接続を使えば、クライアントとサーバー間のスループットが向上することがあります。

接続数の増加にはそれなりの影響があります。接続数が増えると、各接続を維持するために必要なカーネルリソースの使用量も増えます。

コミットレベル

変更の可能性あり

rpcmod:clnt_idle_timeout

備考欄

クライアントとサーバー間の接続が終了するまでにアイドル状態を維持できる、クライアント側の時間の長さを制御します。

データ型

long 整数 (32 ビットプラットフォームでは 32 ビット、64 ビットプラットフォームでは 64 ビット)

デフォルト

300,000 ミリ秒 (5 分)

範囲

32 ビットプラットフォームでは 0 から 2³¹ - 1

64 ビットプラットフォームでは 0 から 2⁶³ - 1

単位

ミリ秒

動的か

はい

検査

なし

どのような場合に変更するか

クライアント側でどのくらいの間アイドル状態であれば接続を閉じるかを変更する場合は、このパラメータを使用します。システムリソースが浪費されるのを防ぐために、接続を閉じるまでの時間を短縮する場合などです。

コミットレベル

変更の可能性あり

rpcmod:svc_idle_timeout

備考欄

クライアントとサーバー間の接続が終了するまでにアイドル状態を維持できる、サーバー側の時間の長さを制御します。

データ型

long 整数 (32 ビットプラットフォームでは 32 ビット、64 ビットプラットフォームでは 64 ビット)

デフォルト

360,000 ミリ秒 (6 分)

範囲

32 ビットプラットフォームでは 0 から 2³¹ - 1

64 ビットプラットフォームでは 0 から 2⁶³ - 1

単位

ミリ秒

動的か

はい

検査

なし

どのような場合に変更するか

サーバー側でどのくらいの間アイドル状態であれば接続を閉じるかを変更する場合は、このパラメータを使用します。システムリソースが浪費されるのを防ぐために、接続を閉じるまでの時間を短縮する場合などです。

コミットレベル

変更の可能性あり

rpcmod:svc_default_stksize

備考欄

カーネル RPC サービス スレッドに対するカーネルスタックのサイズを設定します。

データ型

整数 (32 ビット)

デフォルト

デフォルト値は 0 です。この場合、スタックサイズはシステムデフォルトに設定されます。

範囲

0 から 2³¹ - 1

単位

バイト

動的か

はい。新しく割り当てられるすべてのスレッドに適用されます。スタックサイズはスレッドの作成時に設定されます。したがって、このパラメータの変更は、既存のスレッドには適用されず、新しく割り当てられるすべてのスレッドに適用されます。

検査

なし

どのような場合に変更するか

呼び出し深度が非常に深いために、スタックがオーバーフローし、レッドゾーンの障害が発生するおそれがある場合。トランスポートに対する呼び出し深度が比較的深く、ローカルファイルシステムに対する呼び出しの深さが深いという組合わせは、NFS サービススレッドのスタックがオーバーフローを起こすことがあります。

このパラメータには、プラットフォームのハードウェア pagesize の倍数を設定する必要があります。

コミットレベル

変更の可能性あり

rpcmod:svc_default_max_same_xprt

備考欄

各トランスポート終端の要求を最大でいくつ処理したら、次のトランスポート終端に進むかを制御します。カーネル RPC では、サービススレッドのプールとトランスポート終端のプールが使用されます。個々のサービススレッドは、どのトランスポート終端からの要求でも処理できます。ただし、パフォーマンス上の理由により、次のトランスポート終端に進む前に各トランスポート終端の複数の要求が処理されます。このアプローチにより、不足を避け、パフォーマンス上の利点を得ることができます。

データ型

整数 (32 ビット)

デフォルト

8

範囲

0 から 2³¹ - 1

単位

要求

動的か

はい。ただし、トランスポート終端を切り替える前に要求を最大でいくつ処理するかは、トランスポート終端がカーネル RPC サブシステムに構成されるときに設定されます。このパラメータへの変更は、新しいトランスポート終端だけに適用されます。つまり、既存のトランスポート終端には無効です。

検査

なし

どのような場合に変更するか

サービスが、NFS バージョン 2 の WRITE 要求を高速化するクラスタ化などのクライアントの動作を利用できるようにこのパラメータをチューニングすることができます。このパラメータの値を増やすことにより、サーバー側でクライアントの動作の利点をいっそう活用できる可能性があります。

コミットレベル

変更の可能性あり

rpcmod:maxdupreqs

備考欄

コネクションレストランスポートにおける RPC レベルの再転送を検出する、重複要求キャッシュのサイズを制御します。このキャッシュは、クライアントネットワークアドレス、RPC の手順番号、プログラム番号、バージョン番号、および、トランザクション ID でインデックス化されています。このキャッシュにより、非べき等であるかもしれない再転送要求の処理が防止されます。

データ型

整数 (32 ビット)

デフォルト

1024

範囲

1 から 2³¹ - 1

単位

要求

動的か

キャッシュのサイズは動的に決められますが、キャッシュへの高速アクセスを可能にするハッシュキューのサイズは静的に決められます。キャッシュのサイズを著しく大きくすると、キャッシュ内のエントリの検索に長い時間がかかることがあります。

このパラメータの値を 0 に設定しないでください。0 に設定すると、NFS サーバーが非べき等の要求を処理できなくなります。

検査

なし

どのような場合に変更するか

NFS クライアントで不正な障害エラーが検出された場合は、このパラメータの値を調べます。たとえば、ディレクトリの作成が失敗したのに、実際にはディレクトリが作成されている場合は、再転送された MKDIR 要求をサーバーが検出しなかった可能性があります。

キャッシュのサイズは、サーバーの負荷に見合ったものでなければなりません。キャッシュには非べき等の要求が格納されるため、キャッシュでは、要求全体の一部だけしか管理する必要がありません。キャッシュは、クライアントによる再転送を検出できるだけの間、情報を保持していなければなりません。一般に、コネクションレストランスポートのクライアントのタイムアウトは比較的短く、1 秒から 20 秒くらいです。

コミットレベル

変更の可能性あり

rpcmod:cotsmaxdupreqs

備考欄

接続型トランスポートにおける RPC レベルの再転送を検出する、重複要求キャッシュのサイズを制御します。このキャッシュは、クライアントネットワークアドレス、RPC の手順番号、プログラム番号、バージョン番号、および、トランザクション ID でインデックス化されています。このキャッシュにより、非べき等であるかもしれない再転送要求の処理が防止されます。

データ型

整数 (32 ビット)

デフォルト

1024

範囲

1 から 2³¹ - 1

単位

要求

動的か

はい

検査

キャッシュのサイズは動的に決められますが、キャッシュへの高速アクセスを可能にするハッシュキューのサイズは静的に決められます。キャッシュのサイズを著しく大きくすると、キャッシュ内のエントリの検索に長い時間がかかることがあります。

このパラメータの値を 0 に設定しないでください。0 に設定すると、NFS サーバーが非べき等の要求を処理できなくなります。

どのような場合に変更するか

NFS クライアントで不正な障害エラーが検出された場合は、このパラメータの値を調べます。たとえば、ディレクトリの作成が失敗したのに、実際にはディレクトリが作成されている場合は、再転送された MKDIR 要求をサーバーが検出しなかった可能性があります。

キャッシュのサイズは、サーバーの負荷に見合ったものでなければなりません。キャッシュには非べき等の要求が格納されるため、キャッシュでは、要求全体の一部だけしか管理する必要がありません。キャッシュは、クライアント側の再転送を検出できるだけの間、情報を保持していなければなりません。一般に、コネクション型のトランスポートのクライアントのタイムアウトは非常に長く、1 分くらいです。したがって、エントリは、キャッシュに比較的長く留まる必要があります。

コミットレベル

変更の可能性あり