私は、すべてのエンジニアリングユーザーが使用している大規模なサーバーを持っています。これは19のXvncセッションをホストする32コア、256GBシステムで、ユーザーベースには多数のツール、ログインセッションなどが含まれます。すべてのユーザーはNISを介して設定され、NFSにホームディレクトリがあります。さらに、さまざまな自動化プロセスでは、NIS定義のユーザーとNFSマウントファイルシステムを使用します。
コンピュータはCentOS 6.5を実行しており、問題のファイルサーバーはNetAppです。
時々、人々はコンピュータをしばらく実行した後に特定のコンテンツを削除するという問題に断続的に直面します。このエラーは、「デバイス/リソースの使用中」に似ています。 lsofは問題のある項目（ファイルまたはディレクトリ）を表示しません。一定時間が経過すると（通常は管理者を見つけて問題を確認するのにかかる時間より短い）、問題が消えてアイテムを削除できます。
同じ時点でSVNを使用する自動化されたプロセスの1つで、次のエラーが発生しました。
svn: E155009: Failed to run the WC DB work queue associated with '/home/local-user/tartarus/project8/doc/verif/verification_environment/learning/images', work item 930 (file-install doc/verif/verification_environment/learning/images/my-sequence.uml 1 0 1 1)
svn: E000018: Can't move '/home/local-user/tartarus/project8/.svn/tmp/svn-j3XrNq' to '/home/local-user/tartarus/project8/doc/verif/verification_environment/learning/images/my-sequence.uml': Invalid cross-device link
問題のファイルを削除しようとすると、次の結果が表示されます。
rm: cannot remove `project8/doc/verif/verification_environment/learning': Device or resource busy
「間違ったクロスデバイスリンク」を検索すると、svnバージョンについて多くの議論が行われ、他のデバイスからの書き込みはサポートされません。これは通常動作し、バージョン間のsvnリポジトリを実行しないため、私たちとは関係ありません。または、.svnディレクトリが作業コピーと同じデバイスにあるため、デバイス間のストレージです（nfsがマウントされています）。
コンピュータを再起動すると、数週間または数ヶ月以内に問題がなくなることがあります。私の場合、コンピュータの稼働時間は185日に過ぎませんでした。しかし、エンジニアは必要以上に世界を再開することに夢中ではありません。
メインシステムで問題が発生しない限り、他のコンピュータでは同じ問題が発生しないため、ファイルサーバーを原因として除外しました。つまり、プライマリシステムがファイルを移動したり名前を変更したりできない場合は、ファイルを移動したり名前を変更したりすることはできません。
NFSファイルシステムのマウントオプションは次のとおりです。rw,intr,sloppy,addr=10.17.0.199
私の考えでは、これはエンジニアが実行中の漏れによる副作用であるか、一時的な負荷によるバーストなど、どこかでカーネル値が過度に満たされているようです。
制限は25Mファイルで、このコンピュータの最大ファイル数は200K未満であるため、開いたファイルの総数ではありません。
私が何を探して/探すべきかを知っている人はいますか？
ベストアンサー1
短い答え：ローカルNFSはファイルやディレクトリが存在しないと思います。 （はい、少し懐疑的でした）
NFSは古い技術です。トラフィックが多く、急速に変化するファイルには適していません。動的共有ファイルシステムでは、OCFS2（私のお気に入り）やGluster（まあ、ダークサイド）などのクラスタソリューションを試してください。
数年前、私たちは共通のNFSインストールを備えた4つのサーバーを持っていました。これら4つのサーバーはWebアプリケーションサーバーです。ユーザーはサーバーでパッケージを作成し、ファイルが完了したらファイルへのNFSパスを使用してデータベースの行を更新することを開始します。ユーザーのブラウザは、操作が完了したこと、ファイルをダウンロードする必要があることを確認するために10秒ごとに確認します。問題が発生していることがわかります。サーバーはファイルを含むデータベースの行を更新しますが、他のサーバーはユーザーのブラウザから要求を受け取ります。つまり、ファイルを読み込んで「ファイルが見つかりません」というエラーが発生します。
あなたが言ったように、ファイルは管理者が見るときにそこにあります。複数のエンジニアが問題を見つけるのに数週間かかりました。デフォルトでは、データベースに表示される最後に生成されたファイルパスを取得し、そのファイルをログに書き込む10秒のスリープループを実行します。ファイルはそのファイルを作成したシステムでは常に表示できますが、他のシステムでは一定期間はそのファイルを表示できません。サーバー負荷が増加すると、時間間隔が長くなります。
先のとがった上司は、デフォルトのNFSをクラスタファイルシステムに変更したくないので、ワーカーサーバーに「彼」がデータベースにファイルを作成した人であることを保存するようにしました。ユーザーの要求は、ジョブが完了してファイルが生成されたサーバーに要求が届くまで再試行されるため、常にファイルを読み取ることができます。はい、わかりました。決定的な時期。しかし、それは古い技術を維持することを決めたときに得ることができるものです。仕事がうまくいくためには一緒になる必要があります。古い技術は最初のパッチワークでした。 Max HeadroomのFS選択で80年代に戻ったことを歓迎します。
NFS では、すべてのクライアントがすべての変更をリアルタイムで同期することはできません。したがって、あるクライアントがファイル/ディレクトリを作成し、別のクライアントがそれを見ることができない、またはあるクライアントがファイル/ディレクトリを削除しても、別のクライアントがそれがまだ存在していると思う状況が引き続き発生します（使用しようとするまで -申し訳ありません）。
我々は、ファイルを読み取ろうとする前に、システムがクライアントキャッシュを再同期するために様々なトリックを試みた。起こりませんでした。
私の助言: あなたのFSを今世紀に持って来なさい。 （磁束コンデンサ@88mphをお試しください）