私は、NFS 4 を実行する CentOS 6.4 ファイルサーバーを所有しており、いくつかの XFS ファイルシステムを提供しています。このサーバーには数十のクライアントが接続されています。今日、クライアントの速度が極端に低下しました。サーバーからマウントされた NFS 共有にアクセスすると、クライアントがハングしたり、数分後にしか応答しなくなったりしました。サーバー自体では、問題なく共有ファイルシステムにアクセスできました。問題は約 4 時間後に解消しましたが、理由はわかりません。以下を参照してください。
topいくつかのmigrationプロセスとxfssyncdプロセスが異常な量の CPU を消費し、数秒ごとに 0% から 100% まで変動していることが示されました。他のプロセスは目立ってアクティブではありませんでした。top によって報告された全体的な CPU 使用率は、次のように低いものでした。
Cpu(s): 0.0%us, 4.2%sy, 0.0%ni, 95.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
加入者専用セクションにある RHEL サポート エントリを除いて、これについて特に言及しているものをオンラインで見つけることはできませんでしたが、私には見えません。
を実行しましたservice nfs restart。すると、service nfs statusを除く実行中のデーモンが表示されましたnfsd dead but subsys locked。もう一度再起動すると、これはなくなり、nfsd は実行されていましたが、クライアントはまだハングしていました。
xfssyncd 関連の問題に対して提案されたいくつかのことを試しました:
1)mount –o remount /mnt/dataエクスポートされたファイルシステムで実行します。興味深いことに、このコマンドの実行には約 1 分かかり、その間に「ワイルド」プロセスは落ち着きました。しかし、コマンドの実行が終了すると、プロセスは再び CPU 使用率が高くなりました。
2) echo 720000 > /proc/sys/fs/xfs/xfssyncd_centisecsxfssyncd の同期間隔を変更するため。これによって目立った違いは生じませんでしたが、fs は NFS クライアントでビジー状態であり、問題は他の何かであるはずなので、それほど驚くことではありません。
3 週間前、このサーバーで問題が発生しました。.nfsNNN ファイル (削除されたファイルから開いたままアクセスされている) が急速にいっぱいになり、クライアントでエラー メッセージがループしていました。問題のプロセスを強制終了すると、NFS の速度低下は修正されました。[ただし、数日後、ファイル サーバーは .nfsNNN ファイルの問題が発生しないまま再び速度低下し、最終的には再起動するしかありませんでした。当時、異常な CPU レベルのプロセスがいくつかありましたが、それが何だったのかはメモしておらず、現在の問題と同じだったかどうかは思い出せません。]
今日、問題となっている可能性のある開いている .nfsNNN ファイルを再度検索しましたが、何も見つかりませんでした。数か月前にいくつか削除しましたが、現在は変更されていないため、問題ではないと考えました。これらのファイルを削除した後も、違いは見られませんでした。
上記のさまざまなことを試してから約 1 時間後、サーバーは正常に戻り、プロセスmigrationのxfssyncdCPU 使用率が高くなくなりました。何が変わったのかはわかりませんが、再び発生する可能性があると思われるため、これを事前に把握してみたいと思います。
ご提案があればよろしくお願いします。
-M
答え1
私も RHEL 6.10 を使用していますが、同様の問題が発生しています。唯一効果があると思われるのは、NFS クライアントで長時間実行されているユーザー sftp プロセスを強制終了することです。これらのプロセスは、GUI ベースの SFTP クライアント (WinSCP、Nimble Commander など) によって長時間 (10 時間以上) 開いたままになっていたものです。
監視では、問題と一致する NFSv3 クライアント アクティビティがいくつか示されていますが、そのアクティビティは、問題の原因とならない他のクライアント (100 台を超えるクライアント) の他の一般的なアクティビティよりも実際には低くなっています。
実際に行われる I/O もそれほど多くありません。
2019 年 12 月 10 日更新: 根本的な原因は、NFS サーバーの XFS クォータだったようです。ユーザーのホーム ディレクトリにはクォータが課されており、ソフト リミットはハード リミットより 2 GB 低くなっています。一部のユーザーは、完全な Anaconda Python をインストールしようとしましたが、ソフト リミットを超えてしまいました。Anaconda インストーラーには警告を傍受する方法がないようで、ソフト リミットを超えてファイルをダウンロードし続けました。これにより、大量のクォータ警告が生成され、システムが完全に停止し、応答しなくなりました。
「思われる」と言ったのは、証拠が状況証拠だからです。ユーザーがクォータのないディレクトリにインストールを試みたとき、すべて正常に動作しました。