多数のファイルを含むNFSディレクトリでlsコマンドがゆっくり中断されるのはなぜですか？

を実行するときにls *最初に起こるのは、シェルが現在のディレクトリのリストを取得することです。ディレクトリが大きく、サーバーが遅い場合は時間がかかることがあります。

シェルが現在のディレクトリにファイル名のリストを持っている場合は、リストをソートして（ネットワーク対話と比較して非常に高速です）、lsこのlsコマンドは各ファイルを順番に検索してそのメタデータを検索します（stat呼び出されます）ファイルがディレクトリであることを確認するためにファイルがディレクトリである場合は、ディレクトリ自体ではlsなくその内容を一覧表示します。

Ctrl+を押すと、C現在のNFS操作は中断されません。システムが一貫していない可能性があるため、どこでもファイルシステムの操作を中断することはできません。ファイルを読み込んでもアクセス時間が更新されることがあります。ほとんどの場合、ファイルに対する基本的な読み取りまたは書き込み操作は人間の基準に基づいて即座に行われますが、NFSは例外であり、特に遅いネットワークを介して大量のデータを転送する場合はさらにそうです。

したがって、Ctrl+を押すと、C次の効果のみが適用されます。

• シェルが現在ファイル名のリストを生成している場合は、リストが完全に検索されます。
• lsサーバーがメタデータを提供すると、サーバーが起動して現在のファイルのメタデータをインポートします。
• が起動して現在のディレクトリをリストしている場合、リストはls完全に検索されたか、少なくともその一部以降に検索されました。

これはコマンドのエラーではありませんls（コマンドがまだ起動していない可能性があります）。シェルのせいではなく、NFSのせいです。 NFSはかなり遅いです。

仮説：NFSを介してディレクトリを参照すると、予想よりも多くのデータを一度にロードできます。過度のサーバー側IOは、単一のNFS呼び出しに20秒以上かかります。マウントintrオプションを使用すると、Ctrl-Cが進行中の呼び出しを中止できます。

GoogleはREADDIRPLUSを含むNFS呼び出しのリストを見つけました。デフォルトでは、readdir + 各ファイルの stat です。 getaclもあります。つまり、デフォルトではls -l（特定の数のファイルに対して）これを行うNFS呼び出しがあります。各ファイルに対して別々の統計要求を送信する代わりに。

nfs readdirplus用Google - これは合理的なようです。最初の結果は（有料）バグレポートです。

RHEL6：NFSv3 READDIRPLUSは、NFSディレクトリのグロービング速度を大幅に低下させ、パフォーマンスの問題を引き起こします。

• 標準マウントRHEL 6.2では、3000以上のディレクトリを含むディレクトリでglobを実行するのに218秒（ほぼ4分）かかります。
• readdirplus呼び出しを無効にするためにnordirplusオプションを使用して同じディレクトリをマウントすると、同じディレクトリのglobは1.7秒かかります。

それで、これは調査するのに興味深い方向のように見えました。

編集：あなたの例ではls *ワイルドカードも使用しています。 ls .グローバルは避けます。これが特定の問題に影響を与えると、lsではなくシェルでワイルドカードが発生するため、Ctrl-Cの処理方法に影響を与える可能性があります。それが重要かどうか疑わしいが興味深い質問だと思います。

lsNFSディレクトリでこのコマンドを遅く実行するには、いくつかの理由があります。

• ディレクトリが自動的にマウントされないことがあります。
• これらのコンピュータは同じネットワーク上にない場合があります。

しかし、これは具体的な概念ではなく一般的な概念です。ネットワークファイルシステム。ソートせずにファイルを一覧表示するには、ソートせずにファイルを一覧表示しますls -U。マニュアルページlsから

-U 項目をディレクトリー順にソートしません。 one_per_line フォーマット "-1" と一緒に使用すると、ファイルはすぐに表示され、メモリ制限はありません。

ソートを避けるためのいくつかのバリエーションがあります。システムのマニュアルページを確認し、次のいずれかのオプションを試すことができます。

ls -f
ls -U
ls --sort=none

速度低下を引き起こす可能性のあるlsエイリアスがある場合は、\lsまたは\ls -altrまたはlsの他のオプションを試してください。