Linux環境にjavaが表示されます.net.SocketException:開くファイルが多すぎてエラー
4889 ワード
このエラーは、システムカーネルがプロセスに対して開くファイルの数に制限があるため、デフォルトでは1024[root@localhost~]#ulimit-n 1024パラメータを修正し、この制限を大きくする:#vi/etc/security/limits.confは、*-nofile 65535が65535に制限を追加します.「nofile」項目には2つの制限措置があることに注意してください.アイテムの下のhardとsoftです.最大オープンファイル数を有効にするには、この2つの制限を設定する必要があります.「-」文字設定を使用すると、hardとsoftの設定が同時に設定されます.ハードリミットは、ソフトウェアリミットで設定できる最大値を示します.ソフトウェア制限とは、現在のシステムで有効な設定値を指します.hard制限値は、一般ユーザによって低減することができる.でも増やすことはできません.ソフト制限はhard制限よりも高く設定できません.rootユーザーのみがhard制限値を増加できます.マシンを再起動して構成の変更を有効にする[root@localhost~]#ulimit-n 65535----------------------------------------------------なぜこの問題が発生したのですか?これらの例外は、オペレーティングシステム(OS)のリソースの問題と、オペレーティングシステムがJVMプロセスとともにファイル記述子を使い切った理由を示しています(ファイル記述子とは何かを参照).この問題は、通常、複数の同時ユーザがサーバに接続された後に発生します.Javaは、アプリケーションを実行するために必要なクラスを読み込むために多くのファイルを開きます.多くのアプリケーションで多くのファイル記述子が使用され、新しいファイル記述子が不足します.同様に、新しいソケットごとに記述子が必要です.クライアントとサーバは、TCPソケットを介して通信する.サーバとの接続を確立する際、各ブラウザのhttpリクエストにはTCPソケットが使用されます.まず、ファイルディスクリプタを監視し、これらの診断方法がファイルを開いた状態やその他の潜在的な問題をどのように通知するかを理解する必要があります.このトラブルシューティングセクションをオペレーティングシステムで逐次実行した後、ファイル記述子の数を増やす必要がある場合があります.監視ファイル記述子解決方法のガイドラインは、ファイル記述子の総数が少なすぎるか、または一部のファイル記述子が正しく解放されていないかを判断する一般的なガイドラインと考慮事項です.これは、ファイル記述子の総数を異なる時期にチェックし、この数が減少しているか増加しているかを判断する方法で診断できます.この数が減少した場合は、問題が再発しないように、ファイル記述子の最大数を増やす必要があります(異なるプラットフォームでファイル記述子の数を定義する方法).この変更により、接続が切断される前にTIME_を維持できるようになります.WAITステータスの時間を結合します(ファイル記述子はどのように発行されますか?).多忙なサーバでは、デフォルト値(240秒)が他の接続の意図を遅らせ、最大接続数を制限します.この数が増加し続けている場合は、一部の記述子の処理時間が長すぎるかどうかを判断する必要があります(ファイルが正しく閉じられていません-ファイル記述子がいつ発行されますか?)作成したファイルが多すぎるかどうか(たとえば、ドライバライブラリは常に新しいJDBC接続ごとにファイルをロードしています).jarファイルをロードすると、使用するファイル記述子の数を減らすこともできます.各jarファイルには、個別にロードされた単一クラスごとに1つの記述子が使用される場合でも、記述子が使用されます.オペレーティングシステムに依存して、すべてのディスクリプタがどのように使用されるかを監視および診断するには、次のガイドラインを使用します.開いているファイルUnixプラットフォームを確認するには、多くのツールでlsof(LiSt Open Files)Unix管理ツール(Solaris、Tru 64、HP-UX、Linux、AIX)に、開いているファイルおよびネットワークファイルディスクリプタに関する情報が表示されます.これらのタイプ、サイズ、およびi-ノードが含まれます.特定のプロセスの構文は、lsof-pです.
転載先:http://jsx112.iteye.com/blog/935509
******永続的なアプローチ
サーバの再起動設定を有効にするには、永続的に変更する方法を採用します.
vim/etc/security/limits.conf
ドキュメントの最後に追加
(2) vim /etc/pam.d/login
ドキュメントの最後に追加
別のサイトから言い分が見つかりました.この言い方はもっと標準的だと思います.
開くファイルが多すぎます.一般的には、Socketやデータベース接続をタイムリーに閉じていないなど、アプリケーションがリソースの使用を不適切にしているためです.しかし、アプリケーションは確かに多くのファイルハンドルを開く必要があり、システム自体の設定がこの数を制限している可能性があります.異常1 java.net.SocketException: Too many open files
at java.net.PlainSocketImpl.accept(Compiled Code) at java.net.ServerSocket.implAccept(Compiled Code) at java.net.ServerSocket.accept(Compiled Code) at weblogic.t3.srvr.ListenThread.run(Compiled Code)
異常2 java.io.IOException:開くファイルが多すぎます
at java.lang.UNIXProcess.forkAndExec(Native Method) at java.lang.UNIXProcess.(UNIXProcess.java:54) at java.lang.UNIXProcess.forkAndExec(Native Method) at java.lang.UNIXProcess.(UNIXProcess.java:54) at java.lang.Runtime.execInternal(Native Method) at java.lang.Runtime.exec(Runtime.java:551) at java.lang.Runtime.exec(Runtime.java:477) at java.lang.Runtime.exec(Runtime.java:443)
...
1番目の例外は、ベースTCPプロトコルにエラーが影響した場合に放出され、2番目の例外は、I/O動作にエラーが影響した場合に放出されます.
ファイルのオープン数が多すぎると最悪の場合、システムがクラッシュし、サーバを再起動するしかありません.
理由:
オペレーティングシステムで開くファイルの最大ハンドル数が制限ため、複数の同時ユーザがサーバにアクセスする場合によく発生する.各ユーザのアプリケーションサーバを実行するために多くのファイルがロードされるため(newの1つのsocketには1つのファイルハンドルが必要)、ファイルを開くハンドルの欠如を招く.
解決:
できるだけクラスをjarパッケージにします.1つのjarパッケージは1つのファイルハンドルしか消費しません.パッケージしないと、1つのクラスは1つのファイルハンドルを消費します.JAvaのゴミ回収は、ネットワーク接続が開くファイルハンドルを閉じることができず、close()(例えばjava.net.Socket.close()を実行しないと、ファイルハンドルはずっと存在し、閉じることができない.この問題を制御するためにsocketの最大オープン数を設定することも考えられます.オペレーティングシステムに関連する設定を行い、最大ファイルハンドル数を増やします.LinuxはLinuxカーネル2.4にある.xではソースコードを変更し、カーネルを再コンパイルしてから有効になります.Linuxカーネルのソースコードのinclude/linux/fsを編集します.hファイル、NR_FILEは8192から65536に変更され、NR_RESERVED_FILESは10から128に変更された.fs/inodeを編集する.cファイルMAX_INODEは16384から262144に変更された.または/etc/sysctlを編集します.confファイルは2行fs増加する.file-max=65536およびfs.inode-max = 262144 .一般的に、システムの最大オープンファイル数は、4 M毎の物理メモリ256、例えば256 Mとするのが合理的である.開いているファイルハンドルの数はlsof-pで見ることができる.Windowsの最大ファイルハンドルは16384で、タスクマネージャのパフォーマンスに現在開いているハンドルの数が表示されます.
サーバ側の変更:
システムで許可されている最大ファイル数の表示
#cat/proc/sys/fs/file-max
ユーザーごとに許可されている最大ファイル数を表示
ulimit -a
システムのデフォルトはopen files(-n)1024であることがわかり、問題はここに現れます.
システムファイル/etc/security/limits.confでこの数量制限を修正し、
ファイルにコンテンツを追加するには、次の手順に従います.
* soft nofile 65536 * hard nofile 65536
その他の方法:1.ps-ef|grep java(javaはあなたのプログラムを代表して、あなたのプログラムのプロセスを表示します)を使ってあなたのプロセスIDを表示して、ID番号を記録して、プロセスIDが12 2であると仮定します.使用:lsof-p 12|wc-l現在のプロセスidが12のファイル操作状況を表示するこのコマンドを実行するファイル使用状況は1052である.コマンドの使用:ulimit-aユーザーごとに開くことができる最大ファイル数を表示すると、システムのデフォルトはopen files(-n)1024であり、問題はここに発生します.4.次に実行する:ulimit-n 4096 open files(-n)1024をopen files(-n)4096に設定する
これにより、ユーザーが開くことを許可する最大ファイル数が増加します.
転載先:http://jsx112.iteye.com/blog/935509
******永続的なアプローチ
サーバの再起動設定を有効にするには、永続的に変更する方法を採用します.
vim/etc/security/limits.conf
ドキュメントの最後に追加
* soft nofile 65535
* hard nofile 65535(2) vim /etc/pam.d/login
ドキュメントの最後に追加
session required /lib/security/pam_limits.so別のサイトから言い分が見つかりました.この言い方はもっと標準的だと思います.
開くファイルが多すぎます.一般的には、Socketやデータベース接続をタイムリーに閉じていないなど、アプリケーションがリソースの使用を不適切にしているためです.しかし、アプリケーションは確かに多くのファイルハンドルを開く必要があり、システム自体の設定がこの数を制限している可能性があります.異常1 java.net.SocketException: Too many open files
at java.net.PlainSocketImpl.accept(Compiled Code) at java.net.ServerSocket.implAccept(Compiled Code) at java.net.ServerSocket.accept(Compiled Code) at weblogic.t3.srvr.ListenThread.run(Compiled Code)
異常2 java.io.IOException:開くファイルが多すぎます
at java.lang.UNIXProcess.forkAndExec(Native Method) at java.lang.UNIXProcess.(UNIXProcess.java:54) at java.lang.UNIXProcess.forkAndExec(Native Method) at java.lang.UNIXProcess.(UNIXProcess.java:54) at java.lang.Runtime.execInternal(Native Method) at java.lang.Runtime.exec(Runtime.java:551) at java.lang.Runtime.exec(Runtime.java:477) at java.lang.Runtime.exec(Runtime.java:443)
...
1番目の例外は、ベースTCPプロトコルにエラーが影響した場合に放出され、2番目の例外は、I/O動作にエラーが影響した場合に放出されます.
ファイルのオープン数が多すぎると最悪の場合、システムがクラッシュし、サーバを再起動するしかありません.
理由:
オペレーティングシステムで開くファイルの最大ハンドル数が制限ため、複数の同時ユーザがサーバにアクセスする場合によく発生する.各ユーザのアプリケーションサーバを実行するために多くのファイルがロードされるため(newの1つのsocketには1つのファイルハンドルが必要)、ファイルを開くハンドルの欠如を招く.
解決:
できるだけクラスをjarパッケージにします.1つのjarパッケージは1つのファイルハンドルしか消費しません.パッケージしないと、1つのクラスは1つのファイルハンドルを消費します.JAvaのゴミ回収は、ネットワーク接続が開くファイルハンドルを閉じることができず、close()(例えばjava.net.Socket.close()を実行しないと、ファイルハンドルはずっと存在し、閉じることができない.この問題を制御するためにsocketの最大オープン数を設定することも考えられます.オペレーティングシステムに関連する設定を行い、最大ファイルハンドル数を増やします.LinuxはLinuxカーネル2.4にある.xではソースコードを変更し、カーネルを再コンパイルしてから有効になります.Linuxカーネルのソースコードのinclude/linux/fsを編集します.hファイル、NR_FILEは8192から65536に変更され、NR_RESERVED_FILESは10から128に変更された.fs/inodeを編集する.cファイルMAX_INODEは16384から262144に変更された.または/etc/sysctlを編集します.confファイルは2行fs増加する.file-max=65536およびfs.inode-max = 262144 .一般的に、システムの最大オープンファイル数は、4 M毎の物理メモリ256、例えば256 Mとするのが合理的である.開いているファイルハンドルの数はlsof-pで見ることができる.Windowsの最大ファイルハンドルは16384で、タスクマネージャのパフォーマンスに現在開いているハンドルの数が表示されます.
サーバ側の変更:
システムで許可されている最大ファイル数の表示
#cat/proc/sys/fs/file-max
ユーザーごとに許可されている最大ファイル数を表示
ulimit -a
システムのデフォルトはopen files(-n)1024であることがわかり、問題はここに現れます.
システムファイル/etc/security/limits.confでこの数量制限を修正し、
ファイルにコンテンツを追加するには、次の手順に従います.
* soft nofile 65536 * hard nofile 65536
その他の方法:1.ps-ef|grep java(javaはあなたのプログラムを代表して、あなたのプログラムのプロセスを表示します)を使ってあなたのプロセスIDを表示して、ID番号を記録して、プロセスIDが12 2であると仮定します.使用:lsof-p 12|wc-l現在のプロセスidが12のファイル操作状況を表示するこのコマンドを実行するファイル使用状況は1052である.コマンドの使用:ulimit-aユーザーごとに開くことができる最大ファイル数を表示すると、システムのデフォルトはopen files(-n)1024であり、問題はここに発生します.4.次に実行する:ulimit-n 4096 open files(-n)1024をopen files(-n)4096に設定する
これにより、ユーザーが開くことを許可する最大ファイル数が増加します.