Linux (ある種のサーバー) 用に作成したプログラムで問題が発生しています。悪名高い「開いているファイルが多すぎます」というエラーが表示されます。
今まではソケットの問題だと思っていたのですが、調べてみると、Linux から見ればスレッドも「ファイル」のように見えました。
では、ソケットやスレッドもファイル記述子を必要とするのは正しいでしょうか?
2354 次
2 に答える
4
典型的な UNIX または UNIX ライクなシステムでは、次のものはファイル記述子によって表され、ユーザーの観点から (使用できる機能に関して) そのように扱われます: ファイル、パイプ、ソケット (UNIX およびネットワーク ソケットと同様) 、キャラクターデバイス、ブロックデバイス。
スレッドとプロセスは、ユーザーの観点からも、カーネル内でも、ファイルとして識別されません。
問題は、一部のシステムでは最小制限が低すぎることです。そのため、システム全体 (実際にはユーザーまたはグループ全体) の変更を、プロセスが開くことができる上限に設定します。ファイル/etc/security/limits.conf
を変更し、次の行を追加します:
user_name (soft | hard) nofile (some_number_that_specifies_the_limit)
もちろん、すでに述べたように、これは関数を使用してコードで実行でき、呼び出しプロセスsetrlimitによって開かれるファイルの最大数を設定できます。
コマンド ulimit またはコード内の関数を使用してソフト制限を設定すると、通常、許可されたハード制限に達しないのに対し、任意のリソースにハード制限を設定するには root アクセスが必要であることに注意してください。
スレッドに関するコメントについて:生成できるスレッドまたはプロセスの量が制限されているため、作成するスレッドが多すぎると失敗する可能性があります。たとえば、新しいプロセスを取得できない場合にforkerrno を設定すると失敗することがわかります。EAGAINfile-limit と同様に、これはsetrlimitfunction を使用して変更できます。
ただし、作成するスレッドが多すぎることは、「開いているファイルが多すぎます」というエラーとは関係がないことに注意してください。
于 2013-05-16T19:48:49.140 に答える
0
ソケットは確実にファイル ハンドルで表されます。驚くことではありませんが、スレッドがファイル ハンドルによって支えられていると言う人を聞いたことがありません。
いかなる場合でも...
プログラムを起動する前に、シェルから -n オプションを指定してulimitコマンドを使用します。これにより、最大ファイル制限を上げることができます。コードからsetrlimit関数を呼び出して同じことを行うこともできます。
あまり詳細には触れませんでしたが、コードが実際にソケットとスレッドハンドルを使用したときに閉じていないため、ファイル数の制限に達している可能性はありますか?
于 2013-05-16T19:33:28.897 に答える