私はLinux CentOSを実行しているAmazon EC2でSphinx Search Server V2.06（最新の安定版）を実行しています。通常はうまく機能しますが、searchd.logではこのエラーが何度も繰り返し表示されます。
send() failed: 32: Broken pipe
WARNING: last message repeated 6 times
私はこれがある種の切断の状況だと思います（一部のSphinxフォーラムの回答によると）。この問題に対処したいのですが、これが私たちの主な関心事ではありませんが…関連性があるかもしれません。 Sphinxがしばらく実行された後、または（私が知っている限り）過負荷状態で「メッセージの重複」数が増加し、最高100に達します。通常、ほぼ同時に次の致命的なエラーが発生し、Sphinxが終了します。
FATAL: accept() failed: Too many open files
私のシステムのファイル制限を増やすことを検討しましたが、正確に何をすべきかわかりません。これが私のシステムが現在報告している内容です。それでもこのエラーが表示されます。
sysctl fs.file-max ... returns ... fs.file-max = 7017952
ulimit -a ... returns ... open files 1024
ulimit -Hn ... returns ... 4096
ulimit -Sn ... returns ... 1024
この異なる数字が何を意味するのかはわかりませんが、私の問題を解決するために使用できるようです。この記事。スフィンクスの致命的なエラーを修正し、システムが再起動時にもこの「固定」構成を維持することを確認するにはどうすればよいですか？
答え1
役に立つ記事から始めましょう。
- http://www.cyberciti.biz/tips/linux-procfs-file-descriptors.html
- http://unixfoo.blogspot.com/2008/01/kernel-parameter-file-nr-and-file-max.html
- http://www.netadmintools.com/part295.html
- ulimit：ハード制限とソフト制限の違い
しかも既にリストしたもの。
基本的にこれが言う内容は次のとおりです。
- システムあたりの最大オープンファイル記述子数：7017952
- ulimit -a：シェルが開いて起動できるようになったファイル記述子の最大数。
- ulimit -Sn：上記と同じですが、ファイル記述子の最大数に対するソフト制限のみを表示します。
- ulimit -Hn：セッションに対して開かれたファイル記述子のハード制限を表示します。
基本的にあなたがしなければならないことは、lsofプロセスの出力を見て、それがどこで停止するのかを確認することです。ソフト制限を上下に変更して、セッション中に開いているファイル記述子の可能な数を変更できます。ハード制限は下げることができ、ルートのみを増やすことができます。
したがって、以下を見てください。
sysctl fs.file-nr
これにより、出力とともにシステムで開いていて未使用のファイル記述子の総数が提供されます。
lsof -p <pid>
<pid>問題のあるプロセスがある場合は、プロセスで開いているファイルとソケットの数を確認し、制限に達したことを確認できます。
答え2
/etc/security/limits.d/99-searchd.conf次の内容で名前付きファイルを作成します。
searchd hard nofile 16384
searchd soft nofile 8192
その後、サービスを再起動または再起動します。