WebLogic MEM_ARGS 參數設定

  WebLogic用了一段時間之後,偶爾總是會出現OutOfMemory,這對測試環境來說,還只要Restart Server 就可以解決,但是在正式環境上出現可就麻煩大了,因為一Restart Server 所有User就都無法使用系統,所以MEM_ARGS這個參數的設定就很重要。

這是我SIT目前的設定,依不同的系統做不同的設定
MEM_ARGS="-Xms768m -Xmx768m -XX:NewSize=256m -XX:MaxNewSize=256m -XX:MaxPermSize=384m -XX:PermSize=384m -XX:SurvivorRatio=6 -XX:+DisableExplicitGC"
提示:以上記得要寫成一行。

Heap Size設定
-Xms
設定一開始的Heap Size。
-Xmx 設定Heap Size的最大值 (最好是不是超過實體記憶體的80%)。
-XX:NewSize 調整JVM的Young Generation的size大小。
-XX:MaxNewSize 調整JVM的Young Generation的size的最大值。
- Xmn Young Generation的size,NewSize 和 MaxNewSize設定為一樣。
-XX:NewRatio 控制Young generation的比例,如-XX:NewRatio=3表示Young generation與Old generation的比例為1:3,即Young generation佔1/4,Old generation佔3/4。
Young generation又被分成三部分,第一部分Eden,用於生成新的Object。另外兩個部分為Survivor空間,當Eden用完後,會將 Objects複製到"SS1",當SS1空間滿了的時候,再被複製到"SS2",Objects會在Survivor空間不斷的被複製,直到他滿足條件 進入Old generation止。
提示:如果將Heap Size設的越大,GC的週期就會拉長,而且每次GC的時間也會越長。

PermGen space
-XX:PermSize 這一部分是用於存放Class和Meta的訊息,Class在被 Load的時候被放入PermGen space區域,它和和存放Instance的Heap區域不同,GC(Garbage Collection)不會在主程式運行期間對PermGen space進行清理,所以如果你的APP會LOAD很多CLASS的話,就很可能出現PermGen space錯誤。這種錯誤常見在web伺服器對JSP進行pre compile的時候。

整個記憶體配置會像這樣 

-XX:+DisableExplicitGC 加了這個參數會停止掉WLS或是程式內直接呼叫GC,減少不必要的GC,將GC交由JVM去執行。

Garbage Collection描述:
Garbage Collection分多種等級,0級就是全部的垃圾回收(Full GC),會回收Old generation中的垃圾;1級或以上為部分垃圾回收,只會回收Young中的垃圾,會發生OutOfMemory通常是產生於Old generation或Perm段垃圾回收后,仍然沒有記憶體空間來存放新的Java 物件的情況。

當一個URL被訪問時,記憶體的配置過程如下:
A. JVM會試圖為Java的相關對象在Eden中初始化一塊記憶體空間
B. 當Eden空間足夠時,記憶體配置結束。否則到下一步
C. JVM會試圖釋放在Eden中所有不活躍的對象(這是屬於1或更高級的垃圾回收);釋放後若Eden空間仍然不足以放入新對象,則會試圖將部分Eden中活躍的對象放入Survivor區/OLD區
D. Survivor區被用來作為Eden及OLD的中間交換區域,當OLD區空間足夠,Survivor區的對象會被移到Old區,否則被保留在Survivor區
E. 當OLD區空間不足時,JVM會在OLD區進行完全的垃圾收集(0級)
F. 完全垃圾收集后,若Survivor及OLD區仍然無法存放從Eden複製過來的部分對象,就會導致JVM無法在Eden區為新的對象配置出記憶體區塊,產生"out of memory的錯誤"

以我的設定為例:
MEM_ARGS="-Xms768m -Xmx768m -XX:NewSize=256m -XX:MaxNewSize=256m -XX:MaxPermSize=384m -XX:PermSize=384m -XX:SurvivorRatio=6 -XX:+DisableExplicitGC"

在上面的例子中:
YOUNG+OLD: 768M
YOUNG: 256M
Perm: 384M
Eden: YOUNG*6/(6+1+1)=192M
Survivor: YOUNG*1/(6+1+1)=32M

Heap Size: YOUNG+OLD+Perm=1024M

 

  以上是WebLogic記憶體參數的一些基本的設定,太難的我也不會,只是整理一些心得而己,提供做一下參考

 

堆( Heap)是 Java 程序的对象生活的地方,包含活的对象,死的对象以及剩余内存

    当对象不能被运行中的程序的指针所到达时,这些对象成为”垃圾“。

    JVM 的堆大小决定了 VM 花费在收集垃圾上的时间和频度。

    收集垃圾可以接受的速度与应用有关,应该通过分析实际的垃圾收集的时间和频率来调整。

    如果堆的大小很大,那么完全垃圾收集就会很慢,但是频度会降低。

    如果你把堆的大小和内存的需要一致,完全收集就很快,但是会更加频繁。

    调整堆大小的的目的是最小化垃圾收集的时间,以在特定的时间内最大化处理客户的请求。

    在基准测试的时候,为保证最好的性能,要把堆的大小设大,保证垃圾收集不在整个基准测试的过程中出现。

    堆划分为两个区域:新生代和旧生代。

    新生代又分为:Eden 和两片生存空间(survivor spaces)。其中保证有一片空间在任何时间是空的,当垃圾收集发生时, Eden 中的活的对象复制到下一片生存空间,对象就在生存空间之间复制,直到到达最大门限值(老化),然后复制到旧生代。

    Eden 是新的对象分配的地方。

    很多对象分配以后很快成为垃圾,这些对象称为具有 "infant mortality."
    对象生存的时间越长,需要的收集时间也越长,因此,收集变慢。

    你的应用建立和释放对象的速度决定了垃圾收集的频度。因此,在编程时,应注意使用对象的缓冲,而不是新建立对象。

    大多数对象在新生代就已经死去,因此你能有效的调整垃圾收集。如果你能安排大多数对象的生存期小于一个收集时间,那么,垃圾收集是十分高效的。

    错误的”代“配置会导致频繁的垃圾收集,影响系统性能。

    如果系统花费很多的时间收集垃圾,请减小堆大小。

    一次完全的垃圾收集应该不超过 3-5 秒。

    一般说来,你应该使用物理内存的 80% 作为堆大小。

    在最大工作负荷的时候,监视 WebLogic 的性能。

    使用 -verbosegc 选项测量有多少时间和资源用于垃圾收集。

    打开垃圾收集的详细信息输出以及重定向:

    % java -ms64m -mx64m -verbosegc -classpath $CLASSPATH
    -Dweblogic.domain=mydomain -Dweblogic.Name=clusterServer1
    -Djava.security.policy==/bea/weblogic6x/lib/weblogic.policy
    -Dweblogic.management.server=192.168.0.101:7001 -Dweblogic.management.username=system
    -Dweblogic.management.password=systemPassword weblogic.Server >> logfile.txt
    在 Solaris 系统上,采用下面的命令:

    weblogic.Server > server.out 2>&1
    Java HotSpot VM 选项
    标准的选项在各种平台都已经有介绍:

    http://java.sun.com/j2se/1.3/docs/tooldocs/win32/java.html
    http://java.sun.com/j2se/1.3/docs/tooldocs/solaris/java.html
    http://java.sun.com/j2se/1.3/docs/tooldocs/linux/java.html
    以 -X 开头的选项都为非标准选项(并不能在所有的 VM 上实现),在后续的版本中可能会不通知而变更。

    由于 -XX 选项需要特别的系统权限,因此不建议随便使用。

    在 1.3.0 之前的版本, J2SDK 的 Solaris 版本带有一个虚拟机的实现叫做 Exact VM(EVM),从 1.3.0 开始这个虚拟机被 Java HotSpot VM 所取代。

    Java HotSpot VM 目前认识下面的 -X 选项:

    -Xincgc 使用训练 GC
    -Xnoincgc 不是用训练 GC(缺省)

    -XX:MaxHeapFreeRatio=<Maximum> 最大堆剩余百分比(缺省 70)

    -X:MinHeapFreeRation=<Minimum> 堆最小剩余百分比(缺省 40)

    -Xint 只作解析 (不作 JIT 编译)

    -XX:+UseBoundThreads 绑定用户级别的线程 (只针对 Solaris)

    -Xmn<Size> 设置年轻一代的大小( young generation )(只对 1.4)

    对象分配在 Eden,并且在这里死亡,当 Eden 满时,引起一个小的收集(minor collection),一些生存的对象被移动到旧生代,如果旧生代需要收集,则引起大收集(major collection ),这会比较缓慢。

    如果 GC 成为瓶颈,那么需要指定代的大小,检查 GC 的详细输出,研究 GC 参数对性能的影响。

    旧生代的收集采用 mark-compact 的方式,其中的一部分叫做”永久代“(permanent generation)很特别,他包括了 JVM 自身的所有反映数据(reflective data),例如类以及方法。

    暂停时间的含义是应用因为垃圾收集而显示出来的短暂停顿。

    吞吐量的含义是在一段比较长的时间内,没有用在垃圾收集的时间和总时间的百分比。

    减少暂停时间的办法可以采用小的年轻代和增量收集,但是这以牺牲吞吐率为代价。

    Footprint 是一批工作进程的集合,以页和缓冲行数计量,在物理内存有限或者有很多处理器的系统里,footprint 可代表伸缩性。

    Promptness 是对象死去的时间和内存变为可用时的时间差,在分布系统中(包括 RMI)需要考虑。

    很大的新生代能提高吞吐率,但是牺牲了 footprint 和 promptness。

    Solaris 的 footprint 可以采用 pmap 命令来查看。

    [GC 325407K->83000K(776768K), 0.2300771 secs]
    [GC 325816K->83372K(776768K), 0.2454258 secs]
    [Full GC 267628K->83769K(776768K), 1.8479984 secs]
    上面的三行是 GC 的详细输出,我们可以看到两次小收集和一次大收集。箭头前后的两个数字代表 GC 后活的对象的组合长度。括号内的数字代表合计的空间,等于堆大小减去一片生存空间。

    除非你遇到暂停的问题,否则,可以分配足够的内存给 JVM,缺省的 64MB 总是太小。

    设置 -Xms 和 -Xmx 为同样的值能提高 JVM 的预测,但是如果你的选择不对的话, JVM 不会补偿。

    当增加处理器时,记得增加内存,因为分配可以并行进行,而 GC 不是并行的。

    NewSize 和 MaxNewSize 绑定新生代的长度的低端和高端,设置为一样大小时和 -Xms 和 -Xmx 一样解决新生代的预测时间。

    如果生存空间太小,拷贝直接进入旧生代,如果太大的话,会空闲在那里。

    除非你碰到过渡的大收集或者暂停时间,否则分配足够的内存给新生代,缺省的 MaxNewSize (32MB) 往往太小。

    如果需要的话,最大的永久代大小可以使用 MaxPermSize 增加。

    直接的 GC 调用可以采用 -XX:+DisableExplicitGC 来关闭。

    对于大服务器 而言,1.4 的 JVM 能提供 64 bit 寻址能力,提供更大的新生代大小,并发收集来减少大收集引起的暂停的影响。

    Java HotSpot Client VM 主要用于减少应用启动时间以及内存的 footprint 。

    Java HotSpot Server VM 和 Java HotSpot Client VM 类似,但是在最大性能上作了调整。用于长期运行的服务应用。

    Solaris 和 Linux 的 J2SE 1.3 随带 Java HotSpot Server VM 预安装。

没有更多推荐了,返回首页