ソケットチャネルを開くときはいつでも。クライアントが受け入れる場合、1つのファイル記述子が内部で作成されるため、Linuxで最大1024のクライアントを作成できます。
しかし、Linuxでファイル記述子の制限を増やすことなく（ulimit -n 20000）、より多くのクライアントを作成したいのですが、Javaでより多くのソケットを作成するにはどうすればよいですか？
2224 次
6 に答える
2
制限RLIMIT_NOFILEは、オペレーティングシステムによって適用され、プロセスが作成できる最高のfdを制限します。開かれるすべてのファイル、パイプ、およびソケットに対して1つのfdが使用されます。
ハードとソフトの制限があります。すべてのプロセス（シェルやjvmなど）はソフト値を変更できますが、特権プロセス（rootユーザーが実行するシェルなど）のみがハード値を変更できます。
a）マシンの制限を変更することが許可されていない場合は、変更されている人を見つけてください。
b）何らかの理由でulimitと入力するのが面倒な場合は、JNA：man setrlimit（2）を使用して基になるシステムコールを呼び出すことができると思います。（.exec（）は組み込みコマンドであるため、機能しません）
Ulimitの操作も参照してください
于 2009-04-29T13:39:57.583 に答える
2
UDP を使用している場合、単一のローカル ソケットで多重化できますか? 着信パケットを送信元アドレスとポートで分けることができます。
TCP の場合は運が悪く、各ソケットを閉じた後のTIME_WAIT期間が事態を悪化させます。
于 2009-04-29T11:29:35.200 に答える
2
ulimit を増やせないのはなぜですか? 人為的な制限のようです。システムにアクセスしてulimitをリセットできるJavaコード（afaik）からは方法がありません-プロセスが開始する前に設定する必要があります-起動スクリプトなどで。
JBoss 起動スクリプトは、Jboss を起動する前に「ulimit -n $MAX_FD」を実行します ...
レン
于 2009-04-29T11:31:04.493 に答える
2
セッションが 1024 個のファイル記述子に制限されている場合、単一の JVM からそれ以上使用することはできません。
ただし、ulimit はプロセスごとの制限であるため、おそらくより多くの JVM を開始することで回避できます (つまり、2048 接続を取得するには、それぞれ 1024 を使用して 2 つの JVM を開始します)。
于 2009-04-29T11:23:53.073 に答える
1
最近、Java プロセスが多くの「開いているファイルが多すぎます」という例外をスローしていたため、ulimit を引き上げました。
現在は 65536 で、問題はありません。
于 2009-04-29T15:34:12.613 に答える
0
膨大な数の接続に対処することを本当に検討している場合、それをスケーラブルに行うための最良の方法は、データを受け入れて親プロセスに転送する以外の責任を負わない軽量のデータサーバープロセスを実装することです。
そうすれば、各データサーバーが飽和状態になると、単純に新しいインスタンスを生成して、別の 1024 接続を取得できます。必要に応じて、それらを別のマシンに存在させることもできます。
于 2009-04-29T11:30:12.967 に答える