開くことができるファイル記述子の数を Linux が制限できる場所が複数あります。
以下を確認できます:
cat /proc/sys/fs/file-max
これにより、システム全体のファイル記述子の制限が得られます。
シェルレベルでは、これはあなたの個人的な限界を教えてくれます:
ulimit -n
これは /etc/security/limits.conf で変更できます - これは nofile パラメータです。
ただし、ソケットを正しく閉じている場合は、多数の同時接続を開いている場合を除き、これを受け取るべきではありません。何かがソケットを適切に閉じるのを妨げているようです。それらが適切に処理されていることを確認します.
私は同様の問題を抱えていました.迅速な解決策は次のとおりです:
ulimit -n 4096
説明は次のとおりです。各サーバー接続はファイル記述子です。 CentOS、Redhat、Fedora、おそらくその他では、ファイルユーザーの制限は1024です-理由はわかりません。次のように入力すると簡単に確認できます:ulimit -n
これは、システム最大ファイル (/proc/sys/fs/file-max) とはあまり関係がないことに注意してください。
私の場合、Redis の問題だったので、次のようにしました:
ulimit -n 4096
redis-server -c xxxx
あなたの場合、redis の代わりに、サーバーを起動する必要があります。
TCP には「TIME_WAIT」と呼ばれる機能があり、接続が確実に閉じられるようにします。ソケットが閉じられた後、接続の一方の端がしばらくリッスンし続ける必要があります。
高性能サーバーでは、サーバーではなくクライアントが TIME_WAIT に入ることが重要です。クライアントはポートを開いたままにしておくことができますが、ビジー状態のサーバーは急速にポートを使い果たしたり、開いている FD が多すぎたりする可能性があります。
これを実現するために、サーバーは最初に接続を閉じてはならず、常にクライアントが閉じるのを待つ必要があります。