私が作業しているLinuxクラスターは、最近数分で停止し始めました。この動作の理由は、プロセスが非常に頻繁にD（「ノンストップスリープ」）状態に入り、長い間その状態を維持するためであると判断しました。
残念ながら、この動作は勝手に再現するのが難しいです。一般に、命令が完了する前に数分間Ｄ状態を維持し、同じ命令を直ちに繰り返すと、命令の第２の時間は直ちに完了する。
単一の実行可能ファイルのため、この動作は発生しません。ほとんどすべてのUnixコマンドが脆弱なようです。ls、、、、、、、、名前を指定するだけgrepです。wcfindgitvim
また、同じ動作がクラスタ内のすべてのノードに影響を与えます。
このパターンを見ると、すべてのノードが共有するストレージシステムに問題があるのは間違いないと思いました。残念ながら、私はこの予感をどのように克服すべきかわかりません。
幸いなことに（おそらく）コマンドがD状態に遷移すると、5〜10分間そのままになります。私はこれが状況を調査し、何が起こっているのかについての詳細を得るのに十分な時間を提供すると思います。
私の質問は：ステータスDのプロセスのPIDが与えられたときに何が起こっているのかに関する追加情報を収集するためにどのコマンドを実行できますか？
重要：現在私が主に興味を持っているのは診断。特に、クラスタを再起動して問題を解決することには興味がありません。同じ状況が再発しないようにする方法を教えてくれないからです。
PSこの問題を解決するUnixおよびLinux SEよりも優れたSEサイトがある場合は、喜んで移行します。
ベストアンサー1
クラスタで実行中だと言われました。複数のネットワークコンピュータにまたがるファイルシステムを使用していますか？プロセスの動作が停止すると、通常これが原因です。しばらく（つまり、カーネルコードを実行しているため、I / Oを完了する必要があります）。
最良の選択は、待機プロセスのスタックトレースを取得することです。これは以下のように行われる。
$ sudo su -
# echo w > /proc/sysrq-trigger
# dmesg -T | less -S
lessもちろん、このコマンドはオプションです。
次に、そのスタックトレースを見てください。nfs3_proc_getattrNFSを使用している場合は、ネットワークベースのファイルシステムへの呼び出しを含めることができます。
別の解決策はを実行することですgdb -p <pid>。ただし、プロセスを所有していない場合、またはデバッグモードがオフになっている場合は、そのコマンドラインオプションに権限の問題がある可能性があります。この方法でgdbを起動できる場合は、whereコマンドプロンプトが表示されたら試してみてください。これもスタックトレースを提供します。Dプロセスの進行中にこれらの結果を取得しようとしたことがないため、実際には機能しない可能性があります。
どのコンピュータでもこれらのファイルを編集できる必要がある場合は、良い解決策はありません。それ以外の場合は、HFSなどの方が適している可能性があります。これは、ファイルをローカルにコピーすることを除いて、ネットワークベースのファイルシステムと似ています。したがって、ファイルにアクセスすると、そのファイルは現在使用されているのと同じコンピュータにあり、コマンドは常にすばやく保持されます。
最後の考え：NFSによってプロセスが100％中断される状況がありました。私はそれらについて何もできませんkill -9。これを削除する唯一の方法は、再起動することです。これは、プロセスが現在のカーネル空間にあり、カーネルがこれらのプロセスを安全に削除できないためです。ユーザーモードに戻るには、送信された信号を受信できるまで待つ必要がありますkill。だから、長い間ファイルシステムを使用していませんでした。それは価値がありません。 NFSを正しくマウント解除する前にVMをシャットダウンすると、問題が発生します。 （VMを再起動すると、古いNFSマウントポイントは復元されません。）