サーバーが特定のポートでクライアントネットワーク接続を受け入れることを拒否したのは、ファイル記述子が不足していることが原因である可能性があると言われました。私はこれが何であるかを調べて、ここでそれについて読みました: http://www.netadmintools.com/art295.html
だから私は自分のシステムをテストし、これを手に入れました:
cat /proc/sys/fs/file-nr
1088 0 331287
これは何を意味するのでしょうか?私の制限はかなり高いですが、利用可能なファイル記述子は0ですか?どうして?サーバーでこれを解決するにはどうすればよいですか?
2番目の列は、サーバーをシャットダウンした後も実際には0のままであり、起動直後でも0のままです。
代わりに/ proc/sys/fs/file-maxを見たい
最近のlinux/Documentation/sysctl/fs.txtから:
file-max&file-nr:
カーネルはファイルハンドルを動的に割り当てますが、まだそれらを再び解放することはありません。
File-maxの値は、Linuxカーネルが割り当てるファイルハンドルの最大数を示します。ファイルハンドルの不足に関するエラーメッセージがたくさん表示される場合は、この制限を増やすことをお勧めします。
これまで、file-nrの3つの値は、割り当てられたファイルハンドルの数、割り当てられたが未使用のファイルハンドルの数、およびファイルハンドルの最大数を示していました。 Linux 2.6は、空きファイルハンドルの数として常に0を報告します。これはエラーではなく、割り当てられたファイルハンドルの数が、使用されているファイルハンドルの数と正確に一致することを意味します。
File-maxよりも多くのファイル記述子を割り当てようとする試みは、printkで報告されます。「VFS:file-max制限に達しました」を探してください。
編集:根本的なエラーは、おそらくグローバルファイル記述子が不足しているシステムではなく、プロセスだけです。問題は selectの最大サイズ制限 である可能性があります。
システムファイル記述子の制限に達しているようには見えません。 この回答を参照 。
おそらく、サーバープロセスはselect
を使用しているため、1024記述子に制限されていますか?別のメカニズムに切り替えた場合、たとえばpoll
1024記述子に制限されなくなります。
select()
はfd_set
sで動作します
これはselect.hのPOSIXドキュメントからのものです:
以下はマクロとして定義されます。
FD_SETSIZE
Maximum number of file descriptors in an fd_set structure.
システムでFD_SETSIZE
を検索または出力してみてください。
FD_SETSIZEが小さすぎる場合は、通常は難しいFD_SETSIZE
を増やすよりも、select
から離れようとします。
このような状況でaccept()からどのようなエラーが発生しますか? errnoを確認し、それに応じて報告してください。
マニュアルページによると、accept()は、プロセスごとまたは全体的なファイル記述子の制限に達した場合にEMFILEまたはENFILEを提供します。どちらか(または他に何かあったかどうか)を知ることは役に立ちます。
プロセスごとのファイル記述子の制限があり、多くの場合1024に設定されますが、簡単に増やすことができます。