9

Linux 2.6.36 カーネルを実行していますが、ランダムなエラーがいくつか見られます。のようなもの

ls: error while loading shared libraries: libpthread.so.0: cannot open shared object file: Error 23

はい、私のシステムは一貫して「ls」コマンドを実行できません。:(

dmesg の出力にいくつかのエラーがあります。

# dmesg | tail
[2808967.543203] EXT4-fs (sda3): re-mounted. Opts: (null)
[2837776.220605] xv[14450] general protection ip:7f20c20c6ac6 sp:7fff3641b368 error:0 in libpng14.so.14.4.0[7f20c20a9000+29000]
[4931344.685302] EXT4-fs (md16): re-mounted. Opts: (null)
[4982666.631444] VFS: file-max limit 1231582 reached
[4982666.764240] VFS: file-max limit 1231582 reached
[4982767.360574] VFS: file-max limit 1231582 reached
[4982901.904628] VFS: file-max limit 1231582 reached
[4982964.930556] VFS: file-max limit 1231582 reached
[4982966.352170] VFS: file-max limit 1231582 reached
[4982966.649195] top[31095]: segfault at 14 ip 00007fd6ace42700 sp 00007fff20746530 error 6 in libproc-3.2.8.so[7fd6ace3b000+e000]

明らかに、file-max エラーは疑わしいように見え、一緒にクラスター化されており、最近のものです。

# cat /proc/sys/fs/file-max
1231582
# cat /proc/sys/fs/file-nr
1231712 0       1231582

これも少し奇妙に思えますが、このシステムで 120 万個のファイルを開いているわけにはいきません。これを使用しているのは私だけで、ローカル ネットワーク外のユーザーには表示されません。

# lsof | wc
  16046  148253 1882901
# ps -ef | wc 
    574    6104   44260

私はいくつかの文書を見ました：

ファイルの最大値とファイル番号:

カーネルはファイル ハンドルを動的に割り当てますが、まだ解放しません。

file-max の値は、Linux カーネルが割り当てるファイル ハンドルの最大数を示します。ファイル ハンドルが不足しているというエラー メッセージが多数表示される場合は、この制限を増やすことをお勧めします。

従来、file-nr の 3 つの値は、割り当てられたファイル ハンドルの数、割り当てられているが未使用のファイル ハンドルの数、およびファイル ハンドルの最大数を示していました。Linux 2.6 は、空きファイル ハンドルの数として常に 0 を報告します。これはエラーではなく、割り当てられたファイル ハンドルの数が、使用されているファイル ハンドルの数と正確に一致することを意味します。

file-max よりも多くのファイル記述子を割り当てようとすると、printk で報告されます。「VFS: file-max limit reached」を探します。

これを最初に読んだのは、カーネルには基本的に組み込みのファイル記述子リークがあるということですが、それは非常に信じがたいことです。ファイル記述子を解放するために、アクティブに使用されているシステムを頻繁に再起動する必要があることを意味します。私が言ったように、これが真実であるとは信じられません。なぜなら、Linux システムが何ヶ月も (場合によっては何年も) 稼働し続けるのは私にとって普通のことだからです。一方で、ほぼアイドル状態のシステムが 100 万を超えるファイルを開いたままにしていることが信じられません。

修正またはさらなる診断のためのアイデアはありますか? もちろん、システムを再起動することもできますが、これが数週間ごとに繰り返される問題にはなりたくありません。その場しのぎの措置として、ウィンドウを 1 つしか開いていなかったにもかかわらず、lsof の出力が 2000 行近くもあった Firefox を終了しました (!)。久々の問題。(編集: おっと、話が早すぎました。この質問を書き終える頃には、症状が戻っていました/戻ってきました)

助けてくれてありがとう。

4

1 に答える 1

10

質問を開いたままにしておくのは嫌いなので、これを見つけた人のために要約します。

代わりにserverfaultで質問を再投稿することになりました（この記事）

彼らは実際には何も思いつきませんでしたが、さらに調査を行った結果、最終的には NFSv4 の真のバグ、特にサーバー側のロック コードであることがわかりました。5 秒ごとに監視スクリプトを実行している NFS クライアントがあり、rrdtool を使用してデータを NFS マウント ファイルに記録しました。実行するたびに、書き込みのためにファイルをロックし、サーバーは開いているファイル記述子を割り当てました (ただし、誤って解放することはありませんでした)。そのスクリプト (および実行頻度の低い別のスクリプト) により、1 時間あたり約 900 個の開いているファイルが消費され、2 か月後には制限に達しました。

いくつかの解決策が考えられます: 1) 代わりに NFSv3 を使用します。2) 監視スクリプトの実行を停止します。3) 監視結果を NFS ではなくローカルに保存します。4) これを修正する NFSv4 へのパッチを待ちます (Bruce Fields が実際に試してみるためにパッチを送ってくれましたが、時間がありませんでした)。

他の可能な解決策を考えることができると確信しています。

試してくれてありがとう。

于 2011-03-05T17:26:57.073 に答える