<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    走自己的路

    路漫漫其修遠兮,吾將上下而求索

      BlogJava :: 首頁 :: 新隨筆 :: 聯(lián)系 :: 聚合  :: 管理 ::
      50 隨筆 :: 4 文章 :: 118 評論 :: 0 Trackbacks

     星期一早上到了公司,據(jù)稱產(chǎn)品環(huán)境拋出了最可愛的異常—OutOfMemory, 它是這樣來描述他自己的:

    java.lang.OutOfMemoryError: unable to create new native thread

    而且這位仁兄竟然還堂而皇之地同時出現(xiàn)在了3application里面,所有應用全部遭殃。

    那可愛的OOM是如何產(chǎn)生的呢?直接原因是創(chuàng)建的線程太多了,根本原因是某個地方的內(nèi)存限制了。

    搜羅了一下在網(wǎng)上找到了一個計算公式:

    (MaxProcessMemory - JVMMemory – ReservedOsMemory) / (ThreadStackSize) = Number of threads 

    MaxProcessMemory:進程最大的尋址空間,但我想這個值應該也不會超過虛擬內(nèi)存和物理內(nèi)存的總和吧。關于不同系統(tǒng)的進程可尋址的最大空間,可參考下面表格:

    Maximum Address Space Per Process

    Operating System

    Maximum Address Space Per Process

    Redhat Linux 32 bit

    2 GB

    Redhat Linux 64 bit

    3 GB

    Windows 98/2000/NT/Me/XP

    2 GB

    Solaris x86 (32 bit)

    4 GB

    Solaris 32 bit

    4 GB

    Solaris 64 bit

    Terabytes

    JVMMemory: Heap + PermGen

    ReservedOSMemoryNative heap,JNI

    便可推導出單個JVM Instance可支持的最大線程數(shù)的估計值:

    (MaxProcessMemory<固定值> – Xms<初始化值,最小值> – XX:PermSize<初始化值,最小值> – 100m<估算值>) / Xss = Number of threads<最大值>

    在本地(32bit windows)試了試,可達的線程的最大值差不多就是這個數(shù),它不受物理內(nèi)存的限制,會利用虛擬內(nèi)存,從任務管理器看到memory已經(jīng)是5500 m左右了(開了兩個jvm),我機器的物理內(nèi)存是2g,也不知道這個準不準,后來還拋出了“unable to create new native thread”的兄弟“Exception in thread "CompilerThread0" java.lang.OutOfMemoryError: requested 471336 bytes for Chunk::new. Out of swap space?“。

    本地測完了后,就該輪到dev環(huán)境了,linux2.6,64bit,雙核,8G(虛擬機),總的物理內(nèi)存是16g。在上面整了一下,創(chuàng)建到了15000多個線程的時候掛掉了。此時其他application也不能創(chuàng)建新的線程,而且db也報錯了,操作系統(tǒng)不能fork新的線程了。這應該是操作系統(tǒng)的哪里限制了新線程的創(chuàng)建,

    ·         max thread,linux2.6似乎是32000

    ·         最大可用內(nèi)存:物理內(nèi)存+虛擬內(nèi)存

    ·         配置,在linux可以限制可用資源的大小,show一下這些參數(shù)

    core file size          (blocks, -c) 0

    data seg size           (kbytes, -d) unlimited

    file size               (blocks, -f) unlimited

    pending signals                 (-i) 1024

    max locked memory       (kbytes, -l) 32

    max memory size         (kbytes, -m) unlimited

    open files                      (-n) 65536

    pipe size            (512 bytes, -p) 8

    POSIX message queues     (bytes, -q) 819200

    stack size              (kbytes, -s) 10240

    cpu time               (seconds, -t) unlimited

    max user processes              (-u) 16384

    virtual memory          (kbytes, -v) unlimited

    file locks                      (-x) unlimited

    為了進一步確定在linux上一個jvm因為達到了最大尋址空間OOM了,不會影響其他jvm,我在Linux做了進一步測試,一開始用Sun文檔中說的最大尋址空間3G試了一下,發(fā)現(xiàn)根本不對,達到了3G后還是非常high地在創(chuàng)建新的線程。于是出動超級無敵變態(tài)的JVM初始化配置。

    oracle   27408 27017 12 13:45 ?        00:00:07 /home/oracle/ias1013/FWAPP/FWDev/jdk/bin/java -server -Xmx4096m -Xms4096m -XX:+HeapDumpOnOutOfMemoryError -XX:PermSize=4096m -XX:MaxPermSize=4096m -XX:HeapDumpPath=/home/oracle/ias1013/FWAPP/FWDev/j2ee/OC4J_OOMTest/workEnv/log -Xss100m

    結(jié)果在create 3379個線程后,“unable to create new native thread”出現(xiàn)了,這時其他jvm都是可以create新線程的。如果按照上面公式計算,linux 64bit,2.6kernel,它的最大尋址空間肯定超過了300g,當然應該還沒有達到可用內(nèi)存的限制,因為其他JVM還create新線程。

    我還懷疑是不是oracle application server上的某個配置參數(shù)限制了總的線程數(shù),影響了所有application,但我們的產(chǎn)品環(huán)境一個application就是一個單獨的application server。

    現(xiàn)在基本上可以確定是操作系統(tǒng)哪里設置錯了,我想System team的帥哥們應該把產(chǎn)品環(huán)境的某個參數(shù)配置錯了,系統(tǒng)本身的影響肯定不會有了,因為產(chǎn)品環(huán)境上我們只create800左右個線程,就OOM了,那應該就是配置的問題了,懷疑的參數(shù)有下面四個

    max user processes              (-u) 2048

    virtual memory          (kbytes, -v) unlimited

    max memory size         (kbytes, -m) unlimited

    stack size              (kbytes, -s) 10240

    最后發(fā)現(xiàn)只有max user processes virtual memory對總的線程數(shù)有影響,我把max user processes降到2048后,發(fā)現(xiàn)此時只能創(chuàng)建 2000左右個線程了(Xms64m, Xss1m),進一步地把virtual memory下調(diào)到2048000K發(fā)現(xiàn)能創(chuàng)建的就更少了1679Xms64m, Xss1m),而它只會對當前shell起作用,而多個application server應該是不同的shell,所以他是打醬油的。另外兩個參數(shù)好像就是來做做俯臥撐的,操作系統(tǒng)stack size是不應該會有什么影響,我們把它上調(diào)到102400,還是可以創(chuàng)建2000左右的線程數(shù)(max user processes),因為java有自己的線程模型,它的棧的大小是用Xss來控制的。Max memory size不知道是啥東東,照理說如果是最大內(nèi)存應該不會只在旁邊做俯臥撐,那這個參數(shù)到底是春哥還是曾哥,查了一下man ulimit,有下面解釋

                  -a     All current limits are reported

                  -c     The maximum size of core files created

                  -d     The maximum size of a process data segment

                  -f     The maximum size of files created by the shell

                  -l     The maximum size that may be locked into memory

                  -m     The maximum resident set size (has no effect on Linux)

                  -n     The maximum number of open file descriptors (most systems do not allow this value to be set)

                  -p     The pipe size in 512-byte blocks (this may not be set)

                  -s     The maximum stack size

                  -t     The maximum amount of cpu time in seconds

                  -u     The maximum number of processes available to a single user

                  -v     The maximum amount of virtual memory available to the shell

    Has no effect on Linux”就足以證明它確實只是來做做俯臥撐的。最后查出只有“max user processes”會對所有application能創(chuàng)建總的線程數(shù)有限制。



    posted on 2009-09-25 10:55 叱咤紅人 閱讀(34938) 評論(10)  編輯  收藏 所屬分類: J2SE and JVM

    評論

    # re: 剝下“java.lang.OutOfMemoryError: unable to create new native thread”的外衣[未登錄] 2010-01-19 17:16 菜鳥
    我最近總也是碰見OOM(Exception in thread "CompilerThread0" java.lang.OutOfMemoryError: requested 1056888 bytes for Chunk::new. Out of swap space?)
    不知道大俠能否指點下偶?

    1、服務器硬件配置如下:
    Type IBM X3850
    Processor Details 2132 MHz * 16
    Memory 16G
    操作系統(tǒng)是RedHat企業(yè)版5.0,64位服務器

    2、我使用的JDK是jdk-1_5_0_12-linux-i586,應用服務器是Weblogic 9.2,weblogic服務器setDomain.sh文件的參數(shù)配置如下:
    # PATCH_LIBPATH=[myPatchLibpath] (unix)
    # PATCH_PATH=[myPatchPath] (unix)

    . ${WL_HOME}/common/bin/commEnv.sh

    WLS_HOME="${WL_HOME}/server"
    export WLS_HOME

    WLI_HOME="${WL_HOME}/integration"
    export WLI_HOME

    MEM_ARGS="-Xms3072m -Xmx3072m"
    export MEM_ARGS

    if [ "${JAVA_VENDOR}" = "Sun" ] ; then
    if [ "${PRODUCTION_MODE}" = "" ] ; then
    MEM_DEV_ARGS="-XX:CompileThreshold=8000 -XX:PermSize=96m -XX:+UseParallelGC "
    export MEM_DEV_ARGS
    fi
    fi

    # Had to have a separate test here BECAUSE of immediate variable expansion on windows

    if [ "${JAVA_VENDOR}" = "Sun" ] ; then
    MEM_ARGS="${MEM_ARGS} ${MEM_DEV_ARGS} -XX:MaxPermSize=256m"
    export MEM_ARGS
    fi

      回復  更多評論
      

    # re: 剝下“java.lang.OutOfMemoryError: unable to create new native thread”的外衣[未登錄] 2010-01-19 17:17 菜鳥
    我的郵箱是ooxoo024@hotmail.com,請大俠指點下,先謝謝了。  回復  更多評論
      

    # re: 剝下“java.lang.OutOfMemoryError: unable to create new native thread”的外衣 2010-01-20 07:42 叱咤紅人
    帥哥,
    1.用ulimit看一下,虛擬內(nèi)存是否做了限制。這個異常我測試下來是出現(xiàn)在當總內(nèi)存(物理內(nèi)存+虛擬內(nèi)存)不夠的情況下。
    2.用profile工具或者gc log看一下內(nèi)存的使用情況。看程序中是否有內(nèi)存溢出的風險。
    3.出問題時系統(tǒng)中的線程使用情況。kill -3 或者用TDA.  回復  更多評論
      

    # re: 剝下“java.lang.OutOfMemoryError: unable to create new native thread”的外衣 2010-03-22 18:51 zhaixf
    帥哥,我也做了下相應的測試,發(fā)現(xiàn)公式中的:
    便可推導出單個JVM Instance可支持的最大線程數(shù)的估計值:
    (MaxProcessMemory<固定值> – Xms<初始化值,最小值> – XX:PermSize<初始化值,最小值> – 100m<估算值>) / Xss = Number of threads<最大值>
    Xms不會影響創(chuàng)建線程的個數(shù),起作用的應該是:-Xmx
    其他地方和我想的基本一致,但是我在測試過程中遇到了比較奇怪的問題,沒有辦法解釋:下面是我測試的情況,重點關注“-Xmx1692m”,似乎作為了一個分隔線,之上的也能用公式解釋,之下的也能用公式解釋。

    -Xms3060m -Xmx3060m
    -Xss2048k (thread :94)

    -Xms2560m -Xmx2560m
    -Xss2048k (thread :157)

    -Xms2048m -Xmx2048m
    -Xss2048k (thread :221)
    -Xss1024k (thread :598)

    -Xms1792m -Xmx1792m
    -Xss1024k (thread :683)

    -Xms1692m -Xmx1692m
    -Xss1024k (thread :49)(進程自己結(jié)束)

    -Xms1560m -Xmx1560m
    -Xss2048k (thread :31)(進程自己結(jié)束hs_err_pid24865.log)

    -Xms1536m -Xmx1536m
    -Xss2048k (thread :34)(進程自己結(jié)束hs_err_pid24865.log)
    -Xss1024k(thread :100)

    -Xms1024m -Xmx2048m
    -Xss2048k (thread :221)

    -Xms1048m -Xmx1048m
    -Xss2048k (thread :95)

    -Xms560m -Xmx1152m
    -Xss2048k(thread :82)
    -Xss1024k(thread :228)

    -Xms1048m -Xmx3560m
    -Xss2048k (thread :32)(進程自己結(jié)束)  回復  更多評論
      

    # re: 剝下“java.lang.OutOfMemoryError: unable to create new native thread”的外衣 2010-03-22 22:02 ldd600
    @zhaixf
    1. 和Xss值有關,你的結(jié)果也可以說明這一點,或者您可將Xss設置的變態(tài)一點
    2. 您用的是32位還是64位系統(tǒng),您的虛擬內(nèi)存是多大,虛擬內(nèi)存還受其他程序的影響。
      回復  更多評論
      

    # re: 剝下“java.lang.OutOfMemoryError: unable to create new native thread”的外衣 2010-11-17 11:57 higkoo
    不錯,頂起!  回復  更多評論
      

    # re: 剝下“java.lang.OutOfMemoryError: unable to create new native thread”的外衣 2013-02-25 14:52 excite
    數(shù)據(jù)記錄的很詳細,很有參考價值!  回復  更多評論
      

    # re: 剝下“java.lang.OutOfMemoryError: unable to create new native thread”的外衣 2013-04-02 15:17 wxylion1
    good job  回復  更多評論
      

    # re: 剝下“java.lang.OutOfMemoryError: unable to create new native thread”的外衣[未登錄] 2013-05-15 17:09 Ryan
    很好,呵呵有價值的文章。  回復  更多評論
      

    # re: 剝下“java.lang.OutOfMemoryError: unable to create new native thread”的外衣[未登錄] 2015-12-09 15:37 呵呵
    除了公式外,還和max user processes 限定有關吧?  回復  更多評論
      

    主站蜘蛛池模板: 黄页网址在线免费观看| 日本一区免费电影| 四虎影视久久久免费| 7777久久亚洲中文字幕蜜桃 | 亚洲宅男天堂在线观看无病毒| 天天天欲色欲色WWW免费| 久久久久免费看黄a级试看| 日日躁狠狠躁狠狠爱免费视频| 亚洲熟妇无码AV不卡在线播放 | 国产真人无码作爱视频免费| 黄色大片免费网站| 亚洲色偷偷综合亚洲av78| 91亚洲va在线天线va天堂va国产| 久久精品国产亚洲麻豆| 久久久无码精品亚洲日韩软件| 国产高清免费观看| 女人张开腿等男人桶免费视频| 黄在线观看www免费看| 一级毛片**不卡免费播| 免费黄网站在线观看| 成人片黄网站色大片免费观看cn | 亚洲中文字幕视频国产| 国产不卡免费视频| 国产精品黄页在线播放免费| 妞干网免费观看视频| 成人a免费α片在线视频网站| 国拍在线精品视频免费观看| 100000免费啪啪18免进| 2019中文字幕在线电影免费| 91免费国产精品| 黄+色+性+人免费| 99久久99这里只有免费费精品| 99久久免费国产香蕉麻豆| 麻豆高清免费国产一区| 日本zzzzwww大片免费| 免费A级毛片无码无遮挡内射| 麻豆最新国产剧情AV原创免费| 我的小后妈韩剧在线看免费高清版| 日韩国产免费一区二区三区| 亚洲免费网站观看视频| 免费无码看av的网站|