多数の LAN 接続システムが同時にスローダウンする

独立システムから分散システムへの移行の際に、幾つかの共通の問題が生じます。

問題は通常、できるだけ早く新しい構成を稼働させる必要から、 あるいは特定の機能のコストについての認識が欠如しているために起こります。 最大伝送単位 (MTU) および mbufs に関する LAN 構成のチューニング に加えて、その時点では妥当と思われた一連の決定の結果生じた、LAN 特有の異常または最適ではない状態を探してください。

• ネットワーク統計情報を使用して、ネットワークに物理的な問題がないことを確認します。 netstat -v、entstat、tokstat、atmstat、または fddistat などのコマンドで、アダプターに過度のエラーまたは衝突が示されていないことを確認してください。
• ソフトウェアまたはファームウェアのバグの中には、 ブロードキャストまたはその他のパケットで、LAN を散発的に飽和状態にさせてしまうものがあります。

  ブロードキャスト・ストームが発生すると、ネットワークをアクティブに使用していないシステムでさえ、 絶え間のない割り込みや、パケットの受信および処理に CPU リソースが消費されることにより、スローダウンすることがあります。 これらの問題の検出や特定には、通常のパフォーマンス・ツールよりも、LAN 分析装置の方が適しています。

• 2 つの LAN を 1 つのシステムを介して接続していますか。

  システムをルーターとして使用すると、パケットを処理し、コピーするために大量の CPU 時間を消費します。 また、システムによって処理される他の作業からの干渉を受けることもあります。 専用ハードウェア・ルーターおよびブリッジは通常、費用対効果がより高く、堅固なソリューションです。

• それぞれの NFS マウントごとに、明らかな目的がありますか。

  分散構成の開発のある段階で、NFS マウントは、新しいシステムのユーザーに、 元のシステムのホーム・ディレクトリーへのアクセスを与えるために使用されます。 このような使い方をすれば初期の移行は単純になりますが、データ通信コストの負担が続くことになります。 システム A のユーザーに主としてシステム B のデータを、システム B のユーザーに主としてシステム A のデータを使わせているというようなことは、知られていないことではありません。

  NFS を介してファイルにアクセスすると、LAN トラフィック、クライアントおよびサーバーの CPU 時間、およびエンド・ユーザーの応答時間にかなりのコストがかかることになります。 一般的なガイドラインは、ユーザーとデータは通常同じシステム上にあるべきだということです。 例外は、オーバーライドの問題に、リモートのデータに余分の費用と時間をかけるだけの価値があると判断できる場合です。 幾つかの例として、より信頼性のあるバックアップおよび制御のためにデータを集中させる必要がある場合、または、 すべてのユーザーが確実にプログラムの最新バージョンを使用する必要がある場合が挙げられます。

  これらの必要性やその他の必要性によって、NFS クライアント/サーバー交換の有効なレベルが要求される場合は、 多数のシステムを、一部はサーバー、一部はクライアントとして持つより、1 つのシステムをサーバーの役割専用にする方が適しています。

• プログラムはリモート・プロシージャー・コール (RPC) を使用するため、正確かつ正当に移植されていますか。

  プログラムを分散環境に移植する最も簡単な方法は、プログラム呼び出しを 1:1 で RPC に置き換えることです。 あいにく、ローカル・プログラム呼び出しと RPC のパフォーマンスの格差は、ローカル・ディスク入出力と NFS 入出力との格差よりさらに大きくなります。RPC が本当に必要であるという前提の場合は、可能であれば必ず、 それらをバッチ処理するようにしてください。