weblogic too many open files 問題解決集錦

Too many open files>

weblogic產生這個錯誤之後，就會拒絕服務，這時經過IE已經訪問不了了。因此接下來就會出現apache報下面的錯誤：

[Tue May 30 13:00:57 2006] [error] CONNECTION_REFUSED [os error=0, line 1600 of ../nsapi/URL.cpp]: 218.206.70.193:7001 errno= 0

這時訪問apache會提示和weblogic的橋出了問題。

這個問題已經遇到不少次了，但一般都是夜間，次日查看日誌的時候，會發現那個時候確實訪問量比較大。查看當時的鏈接狀況能夠看到，apache和java鏈接都700多。看了網上的說明，調整了系統參數、調整了weblogic的設置等，都不見效。
http://www.bea.com.cn/support_pattern/Too_Many_Open_Files_Pattern.html
http://e-docs.bea.com/wls/docs81/perform/index.html

今天又出現這個狀況了，不過是白天，和web應用的做者一塊兒對weblogic的狀況進行了觀察。

經過weblogic控制檯，能夠看到Throughput這裏大都是在處理1左右的訪問，Queue Length這裏卻在不停的漲，開始就對Thread count作了修改，從50調整到了400，可是仍是能夠看到Thread會用完，一會Queue Length就又漲起來了。

分析一下就能夠知道，狀況應該是Queue的線程對訪問的處理速度太慢，致使須要處理的隊列愈來愈多。須要處理隊列的增加速度比隊列的處理速度慢，這樣無論有多少線程，確定最後都會致使不夠用。

如今你們就開始考慮問題是否是出在應用這裏了，應用執行速度慢，weblogic線程就會一直佔着，就會致使線程用盡。而實際上確實是應用這裏的問題。

應用對訪問的處理速度很快，有訪問進來就先放到隊列，而隊列的處理速度倒是500ms處理一下，這樣一秒也就處理2個。這樣問題的緣由就很明確了，1s內外部訪問應用可能有10來次，而應用才處理2個，因此天然會將線程佔滿了。

調整隊列處理速度以後問題就解決了，空閒線程一直是400。

=======================================================================

一，什麼狀況下，會新建和打開文件：
1，A JVM opens many files in order to read in the classes required to run your application.
High volume applications can use a lot of files in many ways.
2，each new socket requires a file. Clients and Servers communicate via TCP sockets.
3，Each browser's http request consumes TCP sockets when a connection is established to a Server.


二，文件描述符的釋放：（文件描述符是由無符號整數表示的句柄。進程使用它來標識打開的文件）
1，在文件關閉或進程終止時被關閉的。
2，若是想重用某個文件描述符，必須關閉與之關聯的全部文件描述符（父進程和子進程：文件描述符能夠繼承，可由子進程使用）。
3，TIME_WAIT 結束時，纔會釋放 TCP 套接字文件描述符。
（在 Unix系統中, TIME_WAIT在kernel參數tcp_time_wait_interval中設置.在Windows中,這個參數定義在 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters的 TcpTimedWaitDelay鍵值
中.  默認值是240秒 (tcp_time_wait _interval 和 TcpTimedWaitDelay)）
4，打開新文件時將會重用關閉的文件描述符

三，查看文件描述符的方法：
1，在UNIX平臺，使用「文件列表」 (lsof) 工具顯示有關打開的文件和網絡文件描述符的信息。
   針對特定的process ,語句就是： lsof -p <pid of process>
   這個命令能夠在異常發生後檢查打開文件的最大數，你也能夠經過lsof –h 顯示相應的語法和選項。
   此程序最新版本可經過如下網址得到：   http://ftp.cerias.purdue.edu/pub/tools/unix/sysutils/lsof/
2, 在WINDOWS平臺，使用handle 工具報告有關打開文件句柄的信息。
   推薦使用Process Explorer 工具查看運行的進程和打開的文件列表.(google查一下)

四， 解決之道：

1，對於引起異常的進程，請按期經過工具或命令檢查該進程打開的文件和/或鏈接。
2，將檢查結果與操做系統對進程和整體的文件描述符限制進行比較。
3，根據檢查結果和實際須要提升 OS 限制來彌補文件描述符不足。並使TIME_WAIT 期間縮短爲一個切合 實際的值。

  注意事項：
  1，若是未正確關閉文件，文件描述符可能未被釋放。
  2，若是子進程使用的描述符未關閉文件，將不能重用該文件描述符。（繼承父進程文件描述符）
  3, TIME_WAIT 結束前，TCP 套接字會使文件描述符保持打開狀態。
  4, 請不要依賴 GC 和對象清除功能來釋放文件描述符

五， 如何修改文件描述符：

操做系統資源限制控制：
可使用的文件描述符總數
單個進程最多能夠打開的描述符數。
例如：
1，Windows: 經過文件句柄,打開文件句柄設置爲 16,384.

2，Solaris: rlim_fd_cur 和 rlim_fd_max
    /usr/bin/ulimit 實用程序定義容許單個進程使用的文件描述符的數量。 它的最大值在 rlim_fd_max 中定義，在缺省狀況下，它設置爲 65,536。 只有ROOT用戶才能修改這些內核值。

3，HPUX: nfile, maxfiles 和 maxfiles_lim
  nfile 定義打開文件的最大數量。 此值一般由如下公式來肯定： ((NPROC*2)+1000)，其中 NPROC 一般爲： ((MAXUSERS*5)+64)。  若是 MAXUSERS 等於 400，則通過計算獲得此值爲 5128。 一般能夠將此值設高一些。maxfiles 是每一個進程的軟文件極限，maxfiles_lim 是每一個進程的硬文件極限。

4，Linux: nofile 和 file-max
    管理用戶能夠在 etc/security/limits.conf 配置文件中設置他們的文件描述符極限，以下例所示。
    soft nofile 1024
    hard nofile 4096
    設置命令以下：
    echo 4096 > /proc/sys/fs/file-max
    echo 16384 > /proc/sys/fs/inode-max

5,AIX: OPEN_MAX
    文件描述符極限在 /etc/security/limits 文件中設置，它的缺省值是 2000。 此極限能夠經過 ulimit 命令或 setrlimit 子例程來更改。 最大大小由 OPEN_MAX 常數來定義。

======================================================================

出現這個異常代表操做系統 (OS) 資源問題和操做系統與 JVM 進程用完文件描述符。

解決方法指導原則
下面是通常指導原則和考慮事項：

• 肯定文件描述符的總數是否太少或者某些文件描述符是否未被正確釋放。

這能夠經過如下方法來診斷：在不一樣的時期檢查文件描述符的總數，肯定此數量是有所減小仍是一直增長。

• 若是此數量有所減小，則應當增長文件描述符的最大數量，以防止該問題再次發生

此變化能夠和減小鏈接在斷開以前保持 TIME_WAIT 狀態的時間結合起來,在繁忙的服務器上，缺省值（240 秒）會延遲其它鏈接企圖，從而將限制最大鏈接數量。

• 若是此數量一直增長，則應當肯定某些描述符的處理時間是否過長（文件沒有正確地關閉）以及所建立的文件是否過多（例如，驅動程序庫一直爲每一個新的 JDBC 鏈接加載文件）。

• 加載 jar 文件還可能減小所使用的文件描述符的數量。每一個 jar 文件都使用一個描述符，即便每一個單獨加載的單一類都將使用一個描述符時也是如此。

unix平臺監控打開文件：

lsof -p <pid>

 

解決方法

增長文件描述符的數量一般將可以解決這種問題，可是您還將須要確保 WebLogic Server 做爲一種應用程序不使用過多的文件，還要確保打開的文件可以正確關閉，以便釋放文件描述符。

solaris上設置文件描述符：

/usr/bin/ulimit -H -n 8192

/usr/bin/ulimit -S -n 8192

 

 曾經遇到前端的Apache TCP性能不佳形成大量TIME_WAIT狀態的鏈接不能釋放，形成WebLogic頻繁出現Too many open files的問題。在重裝主機升級了linux版本，調整了TCP參數後解決了此問題。

======================================================================

單位的系統是基於2EE架構的，採用的中間件是weblogic，操做系統是Solaris的，由多臺服務器構成了應用集羣。系統運行一端時間之 後，出現了打開文件數過多(Too many open files)的錯誤，知道是什麼錯誤，但不知道怎麼改動，上網也找了一些資料都沒有成功，最後在本身和別人的幫助下解決了這個問題，如今簡單的說一下怎麼 作的，你們分享一下。

    當出現問題的時候我用ulimit -a查看了一下系統的打開文件數限制，結果只有256，因而就用調整了這個值，修改了/etc/system文件，增長了以下的內容：
set rlim_fd_cur=8192
set rlim_fd_max=65535

將打開文件數設爲了8192，最大爲65535。重啓機器以後用ulimit -a看了一下，系統的已經變成了8192，覺得問題能解決了，但過了一端時間以後有出現了一樣的問題。網上好多說的改系統的打開文件數就好了，但我這兒卻 失敗了，不知道爲何，若是有誰知道的能夠指教一下。

    因而我又開始查找資料，使用了一個plimit命令查看了一下java進程的打開文件數只有1024，這是weblogic設的正常值，聽一個工程師說如 果打開文件數小於1024則weblogic設的值起做用，若是打開文件數大於1024，則會以操做系統的爲準，但我遇到的問題卻並不是如此，進程的打開文 件數仍是1024，如今都沒想明白。知道了這些以後，因而就把問題放在瞭如何永久修改java的打開文件數上，若是隻是當前服務啓動有效可使用命令  plimit -n 最大打開數  pid(進程號)  實現，但這樣每次重起WLS服務後都須要從新執行命令。

    由於個人環境是weblogic集羣，修改了一個節點管理進程文件(在%bea home%\weblogic81\server\bin目錄下)startNodeManager.sh，添加了行ulimit -n 65535，保存退出就ok了，但有一點要注意，就是必須重啓服務器，不然更改不會有效。重啓以後進程打開文件數就變成了65535，到目前爲止沒再出現 上述問題。

    在另一個tomcat+redhat的系統中也出現了上述的問題，正在解決中，若是解決了再和你們分享tomcat+redhat環境中如何解決該問題。若是有知道的朋友，能夠留言告知，謝謝。

============================================================

個人操做系統是redhat,內核是Linux version 2.4.20，用tomcat做爲中間件，出現了Too many open files錯誤。
經過ulimit -a查看結果爲
open files (-n) 1024

/proc/sys/fs/file-max值爲209600

網上說和file-max的值有關，可是個人都已經209600了，應該不會有問題的，
和ulimit -n看到的不同，

請問ulimit -a和file-max什麼關係，怎麼使ulimit -a查看到的open files信息是我想要設的值，怎麼解決這個問題。

一樣的問題我在weblogic下也遇到過，修改了系統的最大打開文件數系統仍然出一樣的錯誤，後來在weblogic的進程文件中加入了ulimit -n 65535，每次weblogic啓動時，進程的打開文件數都是65535，沒有再出現該問題。

請問在tomcat中如何修改其進程的最大打開文件數，是在startup.sh中加入ulimit -n number語句嗎？

linux下怎麼查看一個進程的最大打開文件數
lsof -p pid | wc -l
看到的好象是當前的打開文件數

===============================================================

個人weblogic常常報too many open files錯誤，BEA的人說是系統的問題。
我該怎麼調整個人solaris8呢？
在/etc/system裏，個人設置是
set rlim_fd_max=8192
set rlim_fd_cur=8192
還有什麼其它的地方要修改的嗎？


< 發表於: 2004-10-25 12:13 一、使用這個命令看一下！設置是否起做用。 # ulimit -n 2048 二、檢查你的java程序，多是java程序沒有關閉形成的！ 最好從程序方面解決，要不性能會有影響！