Weblogic性能调优-通过Thread Dump调优JAVA应用程序

合集下载

weblogic线程快照threaddump分析

weblogic线程快照threaddump分析

Java 的线程线程是指能独立于程序的其它部分运行的执行单元。

JAVA语言能够很好的实现多线程的程序。

我们在调试程序,或者在开发后期需要做性能调优的时候,往往也需要了解当前程序正在运行的线程的状态,正在执行的操作,从而分析系统可能存在的问题。

在阅读本文之间,应对Java线程的编程原理,同步机制有一定了解.产生JAVA线程dumpJAVA 的线程DUMP,就象当前JAVA进程的一个快照,打印出所有线程的状态和调用堆栈,以及Monitor的状态。

在不同的操作系统下,产生线程DUMP的方式是不同的。

在启动程序的控制台里敲:Ctrl - Break,线程的dump会产生在标准输出中(缺省标准输出就是控制台,如果对输出进行了重定向,则要查看输出文件)。

在unix,linux 和MacOS 环境中,在控制台中敲:Ctrl-\,或者,用“kill -3 <pid>” ,或者“kill –QUIT <pid>”。

Pid是用所关注的JAVA进程号,您可以用“ps -ef | grep j ava” 找到,或者使用JDK 5.0中的“jps -v” 命令获得。

在各个操作系统平台,都可以用JDK 5.0工具包中的jstack <pid>这里要注意的是:1. 不同的JAVA虚机的线程DUMP的创建方法和文件格式是不一样的,不同的JVM版本,dump信息也有差别。

本文中,只以SUN的hotspot JVM 5.0_06 为例。

2. 在实际运行中,往往一次dump的信息,还不足以确认问题。

建议产生三次dump信息,如果每次dump都指向同一个问题,我们才确定问题的典型性。

线程分析:1. JVM 线程在线程中,有一些JVM内部的后台线程,来执行譬如垃圾回收,或者低内存的检测等等任务,这些线程往往在JVM初始化的时候就存在,如下所示:"Low Memory Detector" daemon prio=10 tid=0x081465f8 nid=0x7 runnable [0x00000000..0x00000000]"CompilerThread0" daemon prio=10 tid=0x08143c58 nid=0x6 waiting on condition [0x00000000..0xfb5fd798]"Signal Dispatcher" daemon prio=10 tid=0x08142f08 nid=0x5 waiting on condition [0x00000000..0x00000000]"Finalizer" daemon prio=10 tid=0x08137ca0 nid=0x4 in Object.wait() [0xfbeed000..0xfbeeddb8]at ng.Object.wait(Native Method)- waiting on <0xef600848> (a ng.ref.ReferenceQueue$Lock)at ng.ref.ReferenceQueue.remove(ReferenceQueue.java:116)- locked <0xef600848> (a ng.ref.ReferenceQueue$Lock)at ng.ref.ReferenceQueue.remove(ReferenceQueue.java:132)at ng.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)"Reference Handler" daemon prio=10 tid=0x081370f0 nid=0x3 in Object.wait() [0xfbf4a000..0xfbf4aa38]at ng.Object.wait(Native Method)- waiting on <0xef600758> (a ng.ref.Reference$Lock)at ng.Object.wait(Object.java:474)at ng.ref.Reference$ReferenceHandler.run(Reference.java:116)- locked <0xef600758> (a ng.ref.Reference$Lock)"VM Thread" prio=10 tid=0x08134878 nid=0x2 runnable"VM Periodic Task Thread" prio=10 tid=0x08147768 nid=0x8 waiting on condition 我们更多的是要观察用户级别的线程,如下所示:"Thread-1" prio=10 tid=0x08223860 nid=0xa waiting on condition [0xef47a000..0xef47ac38]at ng.Thread.sleep(Native Method)at testthread.MySleepingThread.method2(MySleepingThread.java:53)- locked <0xef63d600> (a testthread.MySleepingThread)at testthread.MySleepingThread.run(MySleepingThread.java:35)at ng.Thread.run(Thread.java:595)我们能看到:线程的状态:waiting on condition线程的调用栈线程的当前锁住的资源:<0xef63d600> 这些信息对我们随后的分析都有用处。

jvm dump参数

jvm dump参数

JVM Dump参数什么是JVM Dump?JVM(Java虚拟机)Dump是指在Java应用程序运行时,将JVM的内部状态转储到文件中的过程。

这些转储文件包含了应用程序在运行时的堆栈跟踪、线程信息、对象实例等重要信息。

通过分析这些转储文件,我们可以了解应用程序在发生故障或异常时的状态,有助于定位和解决问题。

为什么需要JVM Dump?在调试和解决Java应用程序中的问题时,JVM Dump起着关键作用。

它可以提供以下信息:1.内存快照:通过JVM Dump,可以获取应用程序在某个时间点的内存快照。

这对于分析内存泄漏、内存溢出等问题非常有帮助。

2.线程信息:JVM Dump中包含了所有线程的堆栈跟踪和状态信息。

这对于查找死锁、线程阻塞等问题非常有帮助。

3.对象实例:通过JVM Dump,可以获取当前堆中存在的所有对象实例以及它们的引用关系。

这对于分析对象创建和销毁情况、查找对象泄漏等问题非常有帮助。

4.GC信息:JVM Dump中还包含了GC(垃圾回收)的详细信息,包括GC算法、GC线程状态、堆内存使用情况等。

这对于分析GC性能和调优非常有帮助。

综上所述,JVM Dump提供了详尽的应用程序状态信息,帮助开发人员快速定位和解决问题,提高应用程序的稳定性和性能。

如何生成JVM Dump?在Java应用程序中,可以通过以下方式生成JVM Dump:1.使用命令行工具:可以使用jmap命令生成JVM Dump。

例如,执行以下命令将生成一个名为dump.bin的转储文件:jmap -dump:format=b,file=dump.bin <pid>其中,<pid>是Java进程的进程ID。

2.使用JDK工具:JDK提供了一些图形化工具,如jvisualvm、Java MissionControl等,可以通过这些工具生成JVM Dump。

在这些工具中,通常有一个按钮或菜单项可以直接生成转储文件。

weblogic java_option 参数

weblogic java_option 参数

weblogic java_option 参数WebLogic Server提供了一系列的Java选项参数,以控制Java 虚拟机的行为。

以下是一些常用的Java选项参数:1. -Xms: 初始Java堆大小2. -Xmx: 最大Java堆大小3. -XX:PermSize: 初始永久代大小4. -XX:MaxPermSize: 最大永久代大小5. -XX:NewSize: 初始新生代大小6. -XX:MaxNewSize: 最大新生代大小7. -XX:SurvivorRatio: 新生代中Eden区和Survivor区的比例8. -XX:NewRatio: 新生代和老年代的大小比例9. -XX:ParallelGCThreads: 并行垃圾回收线程数10. -XX:+UseParallelGC: 使用并行垃圾回收11. -XX:MaxGCPauseMillis: 最大垃圾回收暂停时间12. -XX:+HeapDumpOnOutOfMemoryError: 在发生OutOfMemoryError时输出堆转储文件13. -Dweblogic.security.SSL.ignoreHostnameVerification=true: 忽略SSL主机名验证14. -Dweblogic.security.SSL.protocolVersion=TLSv1.2: 使用TLSv1.2协议进行SSL/TLS通信15. -Dweblogic.MaxMessageSize: 设置WebLogic通信最大消息大小请注意,这只是一些常用的Java选项参数,您可以根据应用程序的需要进行调整。

对于一些高级调优参数,建议咨询WebLogic Server的官方文档。

《Java性能调优指南》

《Java性能调优指南》

《Java性能调优指南》随着互联网的飞速发展,Java作为一种重要的编程语言,被越来越广泛地应用于各个领域。

但是,Java程序的性能问题也随之出现。

如何调优Java 程序的性能,成为了每个开发人员需要解决的难题。

本文将为大家介绍Java性能调优的指南。

一、JVM参数设置JVM(Java虚拟机)参数设置是Java性能调优的关键。

JVM有众多的参数,不同的参数设置会对Java程序的性能产生不同的影响。

常用的JVM参数设置包括以下几个方面:1. 内存设置内存是Java程序的一大瓶颈。

如果内存设置不合理,会导致Java程序频繁地进行垃圾回收,造成程序的延迟和不稳定。

在设置内存参数时需要注意以下几点:- -Xmx: 最大堆内存,设置合理的最大堆内存大小可以减少JVM的垃圾回收次数,提高程序性能。

- -Xms: 初始堆内存,设置合理的初始堆内存大小可以加快程序启动时间,提高程序性能。

- -XX:NewRatio: 新生代与老年代的比例,如果设置得当,可以减少垃圾回收的次数。

通常新生代的大小为总堆容量的1\/3或1\/4,老年代的大小为总堆容量的2\/3或3\/4。

2. 垃圾回收设置垃圾回收是Java程序中必不可少的一部分。

合理的垃圾回收参数设置可以提高程序性能。

常用的垃圾回收参数设置包括以下几点:- -XX:+UseParallelGC: 使用并行GC,适用于多核CPU。

- -XX:+UseConcMarkSweepGC: 使用CMS GC,适用于大型Web应用程序。

- -XX:+UseG1GC: 使用G1 GC,适用于大内存应用程序。

3. JIT设置JIT(即时编译器)是Java程序中非常重要的一部分。

合理的JIT参数设置可以提高程序的性能。

常用的JIT参数设置包括以下几点:- -XX:+TieredCompilation: 启用分层编译,可以提高程序启动时间和性能。

- -XX:CompileThreshold: JIT编译阈值,设置JIT编译的最小方法调用次数,可以提高程序性能。

Java生产环境下性能监控与调优详解

Java生产环境下性能监控与调优详解

Java⽣产环境下性能监控与调优详解1:JVM字节码指令与 javapjavap <options> <classes>cd monitor_tuning/target/classes/org/alanhou/monitor_tuning/chapter8/javap -verbose Test1.class > Test1.txt 即可保存字节码⽂件会有三个部分组成操作数栈LineNumberTableLocalVariableTablei++和++i 的执⾏效果完全相同多了⼀个压⼊栈顶操作for(int i=0;i<10;i++) {}for(int i=0;i<10;++i) {} 执⾏效果⼀样2:public static void f1() {String src = "";for(int i=0;i<10;i++) {//每⼀次循环都会new⼀个StringBuilder 然后在src.append("A");src = src + "A";}System.out.println(src);}public static void f2() {//只要⼀个StringBuilderStringBuilder src = new StringBuilder();for(int i=0;i<10;i++) {src.append("A");}System.out.println(src);}3:public static String f1() {String str = "hello";try{return str;}finally{str = "imooc";}} 返回 hello 但会执⾏finally 中的代码4:字符串拼接都会在编译阶段转换成stringbuilder5:字符串去重字符串在任何应⽤中都占⽤了⼤量的内存。

weblogic线程池设置

weblogic线程池设置

图形化操作是在工作管理器中新建两个约束min和max如何修改WebLogic 9.x / 10.x 默认线程池大小2010/10/10 12:39 AM | 教主| 技术文章| 2 条评论了已经作者:老王来源:WebLogic中文爱好者官方文档指出,WebLogic 9 / WebLogic 10 的线程池是自调优的,并且在WebLogic 9的时候,通过修改config.xml可以修改默认线程池的最小值、最大值,但是很麻烦。

到了WebLogic 10gR3,连修改config.xml的办法都给取消了。

但是,可以通过在启动脚本增加如下参数,可以指定默认线程池的最小值、最大值:-Dweblogic.threadpool.MinPoolSize=100-Dweblogic.threadpool.MaxPoolSize=500如何修改weblogic默认线程池大小2010年12月27日wei发表评论阅读评论weblogic 9开始使用了线程自调优技术。

通过以下方法设置,可以指定默认线程的最大最小值。

方法一:修改启动脚本参数在启动脚本中,增加如下参数%JAVA_HOME%\bin\java %JAVA_VM% %MEM_ARGS% %JAVA_OPTIONS%=%SERVER_NAME%-Djava.security.policy=%WL_HOME%\server\lib\weblogic.policy-Dweblogic.threadpool.MinPoolSize=100 -Dweblogic.threadpool.MaxPoolSize=500%PROXY_SETTINGS% %SERVER_CLASS%方法二:修改config.xml在config.xml中,增加如下参数<server><name>AdminServer</name><self-tuning-thread-pool-size-min>100</self-tuning-thread-pool-size-min> <self-tuning-thread-pool-size-max>500</self-tuning-thread-pool-size-max> <listen-port>7923</listen-port><listen-address></listen-address></server>经过测试,以上两种方法适合weblogic9,10,11g。

jvm dump参数

jvm dump参数

JVM Dump参数什么是JVM Dump?在Java虚拟机(JVM)中,Dump是指将内存中的数据转储到磁盘上的一个过程。

JVM Dump是一种用于分析和调试Java应用程序的重要工具。

它可以帮助开发人员了解应用程序在运行时的状态,包括线程信息、对象实例、堆栈跟踪等。

JVM Dump参数的作用JVM Dump参数允许开发人员在特定条件下生成Dump文件,以便进行后续分析。

通过使用这些参数,我们可以捕获应用程序在出现问题时的内存快照,从而更好地理解问题所在并进行故障排除。

常见的JVM Dump参数以下是常见的JVM Dump参数及其作用:1.-XX:+HeapDumpOnOutOfMemoryError:当发生OutOfMemoryError错误时,自动生成Heap Dump文件。

这对于分析内存泄漏问题非常有帮助。

2.-XX:+PrintGCDetails:打印详细的垃圾回收信息,包括GC事件、堆大小等。

这对于监视和调优垃圾回收行为非常有帮助。

3.-XX:+PrintGCDateStamps:打印GC事件发生的时间戳。

这对于跟踪GC事件和性能分析很有帮助。

4.-XX:+PrintHeapAtGC:在每次垃圾回收之后打印堆的详细信息。

这对于分析堆中对象的分配和回收情况非常有帮助。

5.-XX:+PrintClassHistogram:打印当前加载的类的直方图信息,包括实例数和内存占用量。

这对于了解应用程序中对象的使用情况非常有帮助。

6.-XX:+PrintVMOptions:打印JVM启动时所有的参数设置。

这对于检查JVM参数是否正确配置很有帮助。

7.-XX:+PrintCommandLineFlags:打印JVM运行时通过命令行设置的标志。

这对于检查JVM运行时参数是否正确生效很有帮助。

8.-XX:OnError=“;”:当JVM发生致命错误时,执行指定的命令。

这对于处理严重故障时采取自定义操作很有帮助。

Weblogic中间件运维经验汇总

Weblogic中间件运维经验汇总

Weblogic中间件运维经验汇总目录关于Weblogic参数调优的运维经验 (2)Weblogic性能调优的处理方法 (5)关于输电项目Weblogic安装的运维经验 (8)Weblogic回收数据库连接数配置的方法 (14)在Apache和Weblogic中分别部署静态页面的方法 (17)Weblogic Server性能调优经验 (20)WeblogicJVM堆参数设置方法 (24)关于Weblogic参数调优的运维经验报送单位:北京公司审核人:类型:业务应用关键字:GC垃圾回收1、引言为了提高维护人员运维水平,以集中与分享日常运行维护经验为目的,现进行典型经验的编制。

2、现象描述部分应用服务器出现宕机现象,在F5上查看时已经掉出集群状态。

3、处理过程停止宕机应用服务器上的Weblogic进程。

/home/weblogic/bea/user_projects/domains/pms/bin/setDomainEn v.sh文件中的启动内存大小并添加垃圾回收机制,修改后如下:MEM_ARGS="-Xms5248m -Xmx5248m -Xmn1536m-XX:SurvivorRatio=6-XX:+UseParNewGC-XX:+UseConcMarkSweepGC-XX:CMSFullGCsBeforeCompaction=20-XX:+UseFastAccessorMethods-XX:+AggressiveOpts"3、修改完成后重启Weblogic服务。

4、原因分析在收到报警信息后,对后台日志进行查看,报错信息如下:Exception in thread "CBM_正常处理任务线程" ng.OutOfMemoryError: Java heap spaceatoracle.jdbc.driver.OracleStatement.prepareAccessors(OracleStatement.ja va:868)atoracle.jdbc.driver.OracleStatement.executeMaybeDescribe(OracleStatem ent.java:1045)atoracle.jdbc.driver.T4CPreparedStatement.executeMaybeDescribe(T4CPre paredStatement.java:839)atoracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatem ent.java:1132)atoracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePrepa redStatement.java:3316)atoracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:3361)经过对报错日志分析,状态检修的CBM处理进程内存溢出报错,导致服务器宕机。

Weblogic应用层优化调试设置

Weblogic应用层优化调试设置

社区Weblogic应用层优化调试设置
以Weblogic为中间件的社区应用层,有以下性能优化设置供参考。

1、设置为生产模式,增大连接数据
进入weblogic console 点击左边对应的域名,勾选右边的生产模式。

2、Weblogic登录超时时间
进入weblogic console界面,点击左边对应的域名,再点击监视,再点击服务器/子系统名称AdminServer ,再点击调整,可以看到如下图。

3、设置weblogic 占用的内存值
进入weblogic安装域名目录所在的bin文件夹,修改setDomainEnv.sh 文件根据物理机的实际情况设置内存值
4、设置应用服务数据库连接数据
打开应用程序xp-app 的jdbc数据连接文件
根据oracle实际连接数修改jdbc连接数
Oracle连接数据查看show parameter processes;
5、不限制事务数量
修改服务的事务处理数量限制,修改xp-app应用服务的jta.properties
超出默认的50会报错误
Caused by: ng.IllegalStateException: Max number of active transactions reached:50
6、优化程序代码
在weblogic安装域目录下的log日志可以看到严重超时方法。

jvm常用调优参数

jvm常用调优参数

jvm常用调优参数
JVM是JavaVirtualMachine的缩写,是Java程序运行的核心。

JVM的调优是优化Java应用程序性能的重要一环,其中调优参数的合理设置是关键。

以下是常用的JVM调优参数:
1. -Xms:设置JVM的初始内存大小,默认为物理内存的
1/64。

2. -Xmx:设置JVM的最大内存大小,超出该内存大小后会触发垃圾回收。

3. -Xmn:设置年轻代的大小,一般设置为总内存的1/3或
1/4。

4. -XX:SurvivorRatio:设置年轻代中Eden区和Survivor区的比例,默认值为8。

5. -XX:NewRatio:设置新生代和老年代的比例,默认值为2。

6. -XX:MaxPermSize:设置永久代的大小,一般设置为
256MB。

7. -XX:+UseConcMarkSweepGC:使用CMS垃圾回收器,可以减少内存抖动。

8. -XX:+UseParallelGC:使用并行垃圾回收器,可提高垃圾回收效率。

9. -XX:+HeapDumpOnOutOfMemoryError:当JVM内存溢出时,生成堆转储文件。

10. -XX:+PrintGCDetails:打印垃圾回收的详细信息。

以上是常用的JVM调优参数,通过合理地设置参数,可以优化Java应用程序的性能。

weblogic优化指南

weblogic优化指南

优化WebLogic一、为WebLogic启动设置Java参数垃圾收集(GC)是指JVM释放Java堆中不再使用的对象所占用的内存的过程,而Java堆(Heap)是指Java应用程序对象生存的空间。

堆大小决定了GC的频度和时间。

堆越大,GC频度低,速度慢。

堆越小,GC频度高,速度快。

所以GC和堆大小是一组矛盾。

为了获取理想的Heap堆大小,需要使用-verbosegc参数(Sun jdk: -Xloggc:<file>)以打开详细的GC输出。

分析GC的频度和时间,结合应用最大负载所需内存情况,得出堆的大小。

通常情况下,我们建议使用可用内存(除操作系统和其他应用程序占用之外的内存)70-80%,为避免堆大小调整引起的开销,设置内存堆的最小值等于最大值即:-Xms=-Xmx。

而为了防止内存溢出,建议在生产环境堆大小至少为256M(Platform至少512M),实际环境中512M~1G左右性能最佳,2G以上是不可取的,在调整内存时可能需要调整核心参数进程的允许最大内存数。

对于sun 和hp的jvm,永久域太小(默认4M)也可能造成内存溢出,应增加参-XX:MaxPermSize=128m。

建议设置临时域-Xmn的大小为-Xmx的1/4~1/3, SurvivorRatio为8堆栈内存优化,修改配置文件:WL_HOME=C:\bea\weblogic81 "%WL_HOME%\common\bin\commEnv.cmd":bea#如果采用的上bea的JDK# JVM Heap(堆内存)最小尺寸为96M,最大尺寸为256Mset MEM_ARGS=-Xms96m -Xmx256m:sun#如果采用的是sun的JDK# JVM Heap(堆内存)最小尺寸为32M,最大尺寸为200M#公共变量对象的内存限制: PermSize:最小尺寸, MaxPermSize :最大允许分配尺寸set MEM_ARGS=-Xms32m -Xmx200m -XX:MaxPermSize=128m监视堆栈使用情况:下载JRockit JDK,该JDK已经自带了JRockit Mission Control工具,目前好像还没有单独下载JRockit Mission Control的地方,于JRockit JDK进行了绑定下载;在C:\bea\jrockit81sp5_142_08\console目录里面运行:C:\bea\jrockit81sp5_142_08\bin\java –Xmanagement -jar ManagementConsole.jar 如何监控weblogic呢?修改weblogic启动脚本startWebLogic.cmd,在里面加入-Xmanagement启动参数:%JAVA_HOME%\bin\java -Xmanagement %JAVA_VM% %MEM_ARGS% %JAVA_OPTIONS% =%SERVER_NAME% -Dweblogic.ProductionModeEnabled=%PRODUCTION_MODE% -Djava.security.policy="%WL_HOME%\server\lib\weblogic.policy" weblogic.Server二、设置与性能有关的配置参数在一个WebLogic域中,配置文件(config.xml)位于与管理服务器通信的机器里,提供WebLogic MBean的长期存储。

weblogic调优参数及监控指标

weblogic调优参数及监控指标

weblogic调优参数对Weblogic的调优主要从SEVER、ExecuteQueue、JDBC等几个方面的相关参数进行调优:一、SERVER在mydomain->Servers->myserver->Configuration->Tuning->“Enable Native IO”中: 1、Native IOEnabledTRUE,表示该Server使用本地I/O2、SocketReaders设置在执行线程中专用做Socket Readers的百分比3、Maximum Open Sockets最大打开Socket数4、Stuck Thread MaxTime堵塞线程时间,超过这个时间没有返回的执行线程,系统将认为是堵塞线程如果weblogic认为某个队列中的所有的线程全部堵塞的话,weblogic将会增加执行线程的数量。

注意:执行线程的数量一旦增加,目前weblogic不会去减少他,如果增加了一些线程以后再次出现overflow的警告,weblogic会继续增加执行线程的数量,一直到达到上限为止。

5、Stuck Thread Timer Interval系统检查堵塞线程的时间间隔6、Low Memory GC Threshold当可用内存小于该百分比时,垃圾回收启动7、Low Memory Granularity Level当两次检测的可用内存变化超过该百分比时,垃圾回收启动8、Low Memory Sample Size在一次检测中的取样次数9、Low Memory Time Interval检测间隔时间10、Accept Backlog等待队列中最多可以有多少TCP连接等待处理,如果在许多客户端连接被拒绝,而在服务器端没有错误显示,说明该值设得过低。

如果连接时收到connection refused消息,说明应提高该值,每次增加25%二、ExecuteQueue在mydomain->Servers->myserver ->Monitoring->Monitor all Active Queues... ->Configuration->weblogic.kernel.Default->1、ThreadCount服务器初始创建的执行线程的数量,设置原则:增大机器的最大并发线程数使处理器利用率达到最大。

weblogic 优化

weblogic 优化

优化WebLogic 服务器性能参数WebLogic 配置文件(config.xml)包含了大量很直观的与性能有关的参数,能通过配置环境与应用程序得到很好的优化。

基于系统的需要调整这些参数不仅能改善单个点的性能,而且能提高整个应用程序性能的可衡量性。

试着采用下列WebLogic配置方法,或许能使你的系统达到最佳状态:一修改运行队列线程数的值。

在WebLogic 中队列元素的线程数等于同时占用运行队列的应用程序的数目。

当任务加入一个WebLogic 实例,它就被放到执行队列中,然后分配给任务一个线程来运行。

线程消耗资源,因此要小心处理这个属性——增加不需要的值,会降低性能。

二,如果可能,使用自带的性能包(NativeIOEnabled=true)。

三,使用特定的应用程序执行队列。

四,使用JDBC连接池时,修改下列属性:n 驱动名称:使用小的驱动或者jDriver。

n 初始容量:设为与最大容量相同的值。

n 最大容量:其值至少应与线程数相同。

五,把连接池的大小设为与执行队列的线程数相同。

六,设置缓冲。

七,为Servlet和JSP使用多个执行队列。

八,改变JSP默认的Java编译器,javac 比jikes或sj要慢。

优化WebLogic提要:n 为WebLogic 启动设置Java 参数。

n 设置与性能有关的配置参数。

n 调整开发与产品模式默认值。

n 使用WebLogic “自有的IO ”性能包。

n 优化默认执行队列线程。

n 优化连接缓存。

n 如何提高JDBC 连接池的性能。

n 设置Java 编译器。

n 使用WebLogic 集群提高性能。

n 监视WebLogic 域。

一、为WebLogic 启动设置Java 参数只要启动WebLogic ,就必须指定Java 参数,简单来说,通过WebLogic.Server 域的命令行就可以完成,不过,由于这样启动的过程冗长并且易于出错,BEA 公司推荐你把这个命令写进脚本里。

常见的jvm调优参数

常见的jvm调优参数

常见的jvm调优参数JVM是Java虚拟机的简称,它是Java程序的运行环境。

在生产环境中,JVM调优非常重要,可以提高应用程序的性能和稳定性。

下面是常见的JVM调优参数:1. -Xms和-Xmx:设置JVM的初始堆大小和最大堆大小。

建议将这两个参数设置为相同的值,避免堆大小变化频繁导致性能问题。

2. -XX:PermSize和-XX:MaxPermSize:设置JVM的初始永久代大小和最大永久代大小。

永久代主要用于存储Java类元数据和字符串常量池等信息。

3. -XX:MaxMetaspaceSize:设置JVM的最大元空间大小。

元空间是永久代的替代品,用于存储类元数据等信息。

4. -XX:NewSize和-XX:MaxNewSize:设置年轻代的初始大小和最大大小。

年轻代主要用于存储新创建的对象。

5. -XX:SurvivorRatio:设置年轻代中Eden空间和Survivor空间的比例。

Eden空间用于存储新创建的对象,Survivor空间用于存储年轻代中经过一次垃圾回收后还存活的对象。

6. -XX:MaxTenuringThreshold:设置对象在年轻代中经过多少次垃圾回收后进入老年代。

可以根据应用程序的内存使用情况适当调整该参数。

7. -XX:ParallelGCThreads:设置并行垃圾回收线程的数量。

建议根据CPU核数适当调整该参数。

8. -XX:+UseG1GC:启用G1垃圾回收器。

G1垃圾回收器是Java 9及以后版本的默认垃圾回收器,它可以更好地处理大堆内存的应用程序。

9. -XX:+HeapDumpOnOutOfMemoryError:在JVM出现内存溢出错误时自动生成堆转储文件。

可以用于分析内存泄漏等问题。

以上是常见的JVM调优参数,通过合理地配置这些参数可以提高应用程序的性能和稳定性。

但需要注意的是,不同的应用程序可能需要不同的配置参数,需要根据实际情况进行调整。

对于LINUX类主机JAVA应用程序占用CPU内存过高的分析方法介绍

对于LINUX类主机JAVA应用程序占用CPU内存过高的分析方法介绍

对于LINUX类主机JAVA应用程序占用CPU内存过高的分析方法介绍在Linux类主机上运行的Java应用程序占用过高的CPU或内存可能是由于多种原因引起的,例如代码问题、配置问题、资源不足等。

为了解决这些问题,可以采取以下分析方法:1. 监控系统资源:首先,需要使用系统监控工具,如top、htop、sar等,来监控CPU利用率、内存使用情况、磁盘IO等系统资源。

通过观察系统资源的变化,确定是否存在CPU或内存资源过高的问题。

2. 分析Java程序:使用Java的诊断工具,如jmap、jstack、jvisualvm等,来分析Java应用程序。

通过这些工具可以获取到程序的堆内存使用情况、线程堆栈信息等,从而查找可能导致内存泄漏或者线程阻塞的问题。

3. 检查系统配置:检查Java虚拟机(JVM)的启动参数和堆内存设置。

虚拟机参数如-Xmx和-Xms用于指定最大堆内存和初始堆内存的大小。

如果堆内存设置过小,可能导致频繁的垃圾回收,从而造成CPU占用过高的问题。

可以通过调整这些参数来优化内存的使用。

4. 垃圾回收分析:通过使用Java的垃圾回收日志分析工具,如GCViewer,可以分析垃圾回收过程中的各项指标,如垃圾收集时间、吞吐量等。

通过分析垃圾回收的情况,可以确定是否存在内存泄漏或者频繁的Full GC现象,从而优化垃圾回收策略。

5. 代码调优:如果发现CPU占用高的问题,可以使用Java的性能分析工具,如jprofiler、YourKit等,来分析程序的热点代码,找出占用CPU资源较多的部分。

然后可以针对这些热点代码进行优化,如改进算法、减少循环次数、使用缓存等。

6.分析外部资源:除了CPU和内存资源外,还需要分析应用程序所使用的其他外部资源,如数据库连接、网络请求等。

可以使用性能分析工具来分析这些外部资源的使用情况,确定是否存在资源泄漏或者资源竞争的问题。

7.优化系统结构:如果经过以上步骤仍然无法解决CPU或内存占用过高的问题,可能需要考虑重新设计系统架构。

weblogic优化

weblogic优化

WebLogic Server Performance and TuningWebLogic Server性能调整Tuning Java Virtual Machines (JVMs)调整java虚拟机Garbage Collection垃圾回收VM Heap Size and Garbage Collection虚拟机堆大小和垃圾回收java堆是java对象存活的地方。

其中存有live对象,dead对象和空闲内存。

当正运行的程序中某个对象不可达时,它就被认为是“garbage”并且准备被回收。

一个最优方法是调整垃圾回收时间在执行时间的5%之内。

java虚拟机的堆大小决定了虚拟机垃圾回收的频率和用时。

要在分析垃圾回收的时间运行时间和频率后再将对大小调整到一个可接受的比率。

如果堆设置的大了,full GC 一次就变慢,但发生频率低。

如果根据你的需要设置堆大小,则full GC一次就变快,但是发生频率高。

调整堆大小的目标是,使给定时间内weblogic server能服务的客户数最大化,与此同时,使java虚拟机花在垃圾回收上的时间最小化。

在benchmarking内为了确保性能,你可能设置很大的堆大小以确保在整个benchmark运行中都不发生垃圾回收。

如果在没有堆空间的情况下运行,你会看到如下错误:ng.OutOfMemoryError <<no stack trace available>>ng.OutOfMemoryError <<no stack trace available>> Exception in thread "main"Choosing a Garbage Collection Scheme选择垃圾回收计划根据所使用的java虚拟机,可以从几个垃圾回收计划来管理你的系统内存。

例如,某些垃圾回收计划更适合特定应用。

weblogic异常高CPU占用率故障

weblogic异常高CPU占用率故障
其中包含java测试程序和WEB-INF部署
WEB-INF中包含web.xml和weblogic.xml两个配置文件,(本人这里建了一个lib文件夹放需要的jar包,这里没有用到;还建了 一个classes文件夹里面放java程序编译好了的class文件) 1.2 配置文件设置 Web.xml代码: DeadLoop examples.servlets.DeadLoop
将上面一步查询出来的最高线程号转换成十六进制数8559转换后即为0x216f然后在threaddump中查询该ቤተ መጻሕፍቲ ባይዱx216f高线程对应信息
weblogic异常高 CPU占用率故障
目录 1. 配置和启动web测试应用 (2) 1.1 创建web应用包 (2) 1.2 配置文件设置 (2) 1.3 java程序 (3) 1.4 添加web应用 (4) 1.5 启动web应用 (5) 2. 高CPU占用探查 (5) 2.1 查询CPU占用情况 (5) 2.2 查询占用CPU最高的进程的线程使用情况 (6) 2.3 在Thread dump中查询该高线程对应信息 (7) 异常高CPU占用率故障试验 1. 配置和启动web测试应用 1.1 创建web应用包

java jvm调优面试题

java jvm调优面试题

java jvm调优面试题在Java开发中,JVM(Java虚拟机)的性能调优是一个非常重要的方面。

优化JVM的性能可以提高应用程序的运行效率和响应速度。

为了帮助读者准备面试,本文将介绍一些与Java JVM调优相关的面试题。

以下是几个常见的问题:问题一:什么是JVM调优?JVM调优是指对Java虚拟机进行优化,以提高Java应用程序的性能和吞吐量。

通过对JVM参数的调整、内存管理以及垃圾收集等方面的优化,可以使Java应用程序更加高效地运行。

问题二:如何调整JVM的参数?可以通过在启动Java应用程序时,使用"-X"参数进行调整。

例如,可以使用"-Xms"参数调整初始堆大小,使用"-Xmx"参数调整最大堆大小。

同时,还可以使用"-XX"参数进行更加细致的调优。

问题三:有哪些常见的JVM参数?常见的JVM参数包括:- "-Xms":设置初始堆大小- "-Xmx":设置最大堆大小- "-XX:NewRatio":设置年轻代与老年代的比例- "-XX:MaxPermSize":设置永久代的最大大小(JDK8之前)- "-XX:MaxMetaspaceSize":设置元数据区的最大大小(JDK8之后)问题四:什么是垃圾收集器(GC)?垃圾收集器是JVM中负责回收无用对象的组件。

垃圾收集器通过标记、清除和压缩等过程来释放不再使用的内存,并将其回收供其他对象使用。

问题五:有哪些常见的垃圾收集器?常见的垃圾收集器包括:- Serial收集器:单线程的、使用复制算法的收集器,适用于小型应用程序或者客户端应用程序。

- Parallel收集器:多线程的、使用复制算法的收集器,适用于需要追求较高吞吐量的应用程序。

- CMS收集器:并发标记清除算法的收集器,适用于需要较短停顿时间的应用程序。

【转】Weblogic挂起、宕机问题分析及优化

【转】Weblogic挂起、宕机问题分析及优化

【转】Weblogic挂起、宕机问题分析及优化出处: /entry/id/2d66195f2b556337012b55bc34a500b1.htmlWeblogic挂起、宕机问题分析及优化1) 中间件weblogic简介1.略2) weblogic挂起1.表现现象∙服务器不在响应请求,页面很久还打不开∙请求超时∙请求处理的时间越来越长通常,服务器挂起不会表现为服务器崩溃,进入控制台查看server实例状态,仍然是RUNNING状态,进到请求队列里面查看,发现空闲执行线程没有了,如下图:查看server状态:访问WebLogic中文博客查看所有队列:访问WebLogic中文博客⒉分析服务器挂起的原因⑴ webloigc各线程队列工作原理Execute Queueweblogic.admin.HTTP: 供与管理控制台的通信用weblogic.admin.RMI: 管理服务器和被管理服务器上都有这个队列,它是供管理的交通之用weblogic.kernel.Default: 执行队列线程weblogic.kernel.System: weblogic自用访问WebLogic中文博客即ListenThread传入àsocket reader线程池(本地性能包) à执行线程池,对每个server做threaddump的时候正常可以看到如下图线程信息,如果没有看到socket reader或者是ListenThread,那么这个server工作是不正常的,此时server可能处于fail状态访问WebLogic中文博客访问WebLogic 中文博客 ListenThread负责响应所有请求,然后传入给socket reader 线程,Socket Reader 线程接受来自监听线程队列的传入请求,并将该请求放入执行线程队列,执行线程负责执行具体任何。

上面其中任何一个环节工作不正常均有可能造成挂起的现象。

tomcat性能调优方案

tomcat性能调优方案

tomcat性能调优方案在开发和部署Web应用程序时,Tomcat是一款广泛使用的Java Servlet容器。

然而,随着业务的增长和用户量的上升,Tomcat性能问题可能会成为一个挑战。

为了确保应用程序的高效运行,我们需要采取一些性能调优措施。

本文将介绍一些Tomcat性能调优方案,以提高应用程序的性能和响应速度。

一、优化Tomcat服务器配置1. 调整内存参数:通过修改Tomcat的启动脚本‘catalina.sh’(Linux)或‘catalina.bat’(Windows),可以配置JVM的内存参数。

可以增加-Xms和-Xmx参数来增加JVM的初始堆大小和最大堆大小。

适当调整这些参数可以提高应用程序的内存管理效率,从而提高性能。

2. 调整连接器配置:Tomcat使用连接器来处理HTTP请求,可以通过调整连接器的配置参数来提高性能。

例如,调整maxThreads参数来增加同时处理请求的线程数,增加acceptCount参数来增加等待处理的请求队列长度,以及调整keepAliveTimeout参数来控制HTTP连接的持久化时间等。

二、优化应用程序代码1. 减少HTTP请求:每次HTTP请求都会消耗系统资源,并且增加网络延迟。

通过优化应用程序代码,减少不必要的HTTP请求可以提高性能。

例如,可以使用CSS sprites来减少图片加载请求,合并和压缩JavaScript和CSS文件来减少文件加载请求等。

2. 使用缓存:合理使用缓存机制可以减少对数据库和其他资源的请求次数,提高应用程序的性能。

例如,可以使用缓存技术来缓存数据库查询结果、页面片段或整个页面,以减少对数据库和服务器的访问次数。

3. 避免同步阻塞:多线程并发请求可能会导致同步阻塞,影响应用程序的性能。

通过合理使用同步机制和锁机制,避免同步阻塞可以提高性能。

例如,使用线程池来管理并发请求的线程,使用并发集合类来替代同步集合类等。

三、数据库优化1. 数据库索引优化:在使用数据库时,合理的索引设计可以大大提高查询性能。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

理解和探查内存不足/内存泄漏OutOfMemoryError/Memory Leak Analyze & UtilitiesDemonstrate II(AIX)理解和探查内存不足/内存泄漏听完这次Webinar,您将能够:q了解Java基本内存管理基本概念q了解发生内存不足/内存泄漏错误的原因和症状q了解如何解决内存不足/内存泄漏错误MENU•Java内存管理的基本概念•内存不足和内存泄漏错误的原因和症状•使用分析工具解决内存不足和内存泄漏错误•预防内存不足和内存泄漏•OutOfMemory分析实例…Java内存–Java堆内存(heap)…Java堆内存(heap):–是JVM用于分配Java对象的内存,包含活动对象和不可用对象–堆大小通常是在服务器启动时使用java命令中的–Xms(最小)–Xmx(最大)标志来定义。

…本地内存(native memory):–是JVM用于其内部操作的本地内存(非Java内存)–JNI代码和第三方本地模块(例如,本地JDBC驱动程序)也使用本地内存–最大本地内存大小取决于以下因素:•操作系统进程内存大小限制•已经指定用于Java堆的内存…进程内存大小:–32位操作系统,理论最大值2的32次方=4G–进程内存=Java内存+本地内存+加载的可执行文件和库+操作系统保留内存…垃圾回收 (Garbage Collection, GC):–JVM自动检测和释放不再使用的内存。

–Java运行时JVM会执行GC,这样程序员不再需要显式释放对象。

–通常在空闲内存降低到某一水平或内存分配达到某一数量后自动触发。

…以下OutOfMemory简称OOM…以下Memory Leak简称ML…Heap简称“堆”Java内存问题的两种表现形式…Java内存问题的两种表现形式:–内存不足错误–内存泄漏错误…内存不足错误--明确显示出ng.OutOfMemoryError –没有空闲内存可供JVM或本地代码用于分配新对象或内存块–在Java堆或本地内存中都可能发生…内存泄漏错误--没有错误信息,但是内存几乎耗尽–已经分配好的内存或对象,当不再需要,没有得到释放–内存曲线是一条斜向上的曲线–对Java堆或本地内存都可能产生这个问题–通常最终的状态就会导致OOM错误…通常内存泄漏ML会导致OOM错误,因此两者的探查方法完全相同!Java内存问题的两个主要发生区段…Java内存问题的两个主要发生区段:–Java内存--包括heap堆内存和permanent区–本地内存--包括JVM进程内存和java使用的第三方本地代码…Java内存不足–Java堆内存heap不足,无法再分配新对象或内存块–permanent区内存不足,无法再加载类到内存中(Sun & Hp JDK)…本地内存不足–物理内存不够,无法再得到内存–第三方本地代码有内存泄漏的Bug,例如oracle oci driver本地代码–JVM的JIT或者JVM本身的BugMENU•Java内存管理的基本概念•内存不足和内存泄漏错误的原因和症状•使用分析工具解决内存不足和内存泄漏错误•预防内存不足和内存泄漏•OutOfMemory/Memory Leak错误实例内存不足和内存泄漏错误的典型原因(1)…物理内存不足–物理内存有限,例如只有1G–物理内存很大,但是应用很多,占用太多内存…Swap区大小不够…Weblogic Server压力太大–并发用户太多–大数据量分配应用,例如统计报表…Permanent区太小…用户代码内存不释放–http session放置了大量对象–在内存分配大量数据–用户自己创建太多线程–调用AWT等画图接口…用户代码内存泄漏问题–jdbc连接没有close–分配好的对象没有close和释放内存不足和内存泄漏错误的典型原因(2)…Weblogic Server配置不当–给heap分配的内存太少–session timeout时间太长–EJB pool和Cache的太大…第三方Java应用的内存问题–第三方Java应用也存在内存不足或者泄漏问题…第三方本地代码的内存泄漏问题–第二类JDBC驱动的内存泄漏,例如Oracle Oci Driver–其他第三方本地代码的内存泄漏…JVM本身的内存问题–JIT技术需要消耗更多的本地内存–JVM本身的Bug,例如GC的Bug在 Java 堆中发生的 OOM 的故障症状…如果Java堆发生OOM/ML:–Weblogic Server运行缓慢,响应速度很慢(JVM在频繁的做GC,Java进程占用比较多的CPU)–从console的内存监控曲线看,一直徘徊在顶部–最终JVM抛出ng.OutOfMemoryError异常,stdout或stderr中将显示这则消息–通过thread dump可以看到大部分时间•所有线程都在wait,只有GC线程在工作•很多线程都在申请内存–线程可能会异常退出(即在Thread Dump中看不到这个线程,线程丢失)–持续的Java堆OOM/ML错误偶尔也会导致JVM进程退出服务,通常伴随会产生一个文本Core文件JVM退出时产生的文本Core文件…通常JVM异常退出伴随会产生一个文本Core文件–除了OOM,JVM也会因为其他原因异常退出–IBM JDK -- javacore****.txt文件小节回顾ü内存不足和内存泄漏错误的典型原因üOOM 错误相关故障症状在本小节中,我们讲述了以下内容:MENU•Java内存管理的基本概念•内存不足和内存泄漏错误的原因和症状•使用分析工具解决内存不足和内存泄漏错误•预防内存不足和内存泄漏•OutOfMemory错误实例使用分析工具来分析OOM问题…发生Java Heap OOM问题时,无法定位到问题,最终的办法只能使用分析工具来做分析。

…常用内存分析工具–HeapAnalyzer or HeapRoots for IBM JDK-离线分析…HeapAnalyzer/HeapRoots是一款针对IBM JDK的内存文本镜像HeapDump的分析工具…特性:–离线分析,不影响生产系统–需要得到IBM JDK内存镜像–只支持IBM JDK–HeapRoots字符界面,HeapAnalyzer是HeapRoots的图形界面…启动方式:–Kill -3 <pid>得到heapdump文件–启动HeapAnalyzer或者HeapRoots,加载heapdump文件–图形化分析…HeapDump是IBM JDK Heap内存的一个文本镜像,默认生成位置在Weblogic Server启动目录下,通常是Domain目录…如果得不到HeapDump,可能是禁止生成…HeapDump的生成开关–export IBM_HEAPDUMP=true–export IBM_HEAP_DUMP=true–export IBM_HEAPDUMP_OUTOFMEMORY=true–export IBM_JAVADUMP_OUTOFMEMORY=true–export IBM_JAVACORE_OUTOFMEMORY=true–export IBM_HEAPDUMPDIR=<directory_path>…注意:–通常HeapDump会比较大,尤其是在Heap内存设置很大的情况下–为了重现问题,得到现场数据,建议先把HeapDump调小,推荐1G以下–在Window上,如果HeapDump大于1G,可能会无法打开,出现OOM错误启动HeapAnalyzer需要指定Xmx参数…启动界面…内存按树状引用关系显示…内存按对象和类型显示…找到怀疑泄漏的内存对象小节回顾ü内存分析工具üHeapAnalyzer /HeapRoots 在本小节中,我们学习了以下内容:MENU•Java内存管理的基本概念•内存不足和内存泄漏错误的原因和症状•诊断、定位和解决内存不足和内存泄漏错误•预防内存不足和内存泄漏•OutOfMemory错误实例预防内存不足和内存泄漏…最好的补救不如事先的预防…预防内存不足和内存泄漏–系统管理–代码编写…系统管理–足够的物理内存,设置适当的Swap区大小–最佳的HEAP内存设置–使用最新的操作系统/最新的JDK/最新版本的WLS –使用Weblogic Server认证的JDK–尽量少使用第三方本地代码,或使用Java替代方案–根据应用设置适当的HttpSession Timeout时间–根据应用设置适当的EJB Pool/Cache…代码编写–不要放置大量对象到Session中–不要缓存太多数据–用完的资源一定要close(),例如IO,File,JDBC连接–合理的从数据库取得适量数据–XML解析对大内存的需求–统计和报表业务的负荷问题小节回顾ü预防内存不足和内存泄漏ü系统管理ü代码编写在本小节中,我们讲述了以下内容:MENU•Java内存管理的基本概念•内存不足和内存泄漏错误的原因和症状•诊断、定位和解决内存不足和内存泄漏错误•预防内存不足和内存泄漏•OutOfMemory错误实例OutOfMemory错误实例案例一OutOfMemory错误实例(1)现象…环境IBM AIX 5.2,JDK1.4.2,Weblogic Server 813…刚启动很好,过了一段时间,用户数上来,就发生OOM。

自动产生heapdump和javacore文件…只能重启。

重启过了一段时间又是这样。

OutOfMemory错误实例(1)收集信息…GC日志…JavaCore文件分析…Thread Dump…HeapDump用HeapAnalyserOutOfMemory错误实例(1)- GC日志… <GC(1): freed 30618248 bytes, 97% free (1048443192/1073674752), in 44 ms>… <GC(7): freed 915866016 bytes, 88% free (948327168/1073674752), in 151 ms>… <GC(8): freed 637378736 bytes, 63% free (680325728/1073674752), in 290 ms>… <GC(9): freed 78799496 bytes, 10% free (111009736/1073674752), in 550 ms>… <GC(10): freed 2988992 bytes, 10% free (113998728/1073674752), in 514 ms>… <GC(11): freed 2616648 bytes, 0% free (2616648/1073674752), in 570 ms>… <GC(12): freed 33508896 bytes, 3% free (36125544/1073674752), in 1068 ms>… <GC(13): freed 36543728 bytes, 3% free (36543728/1073674752), in 1096 ms>… <GC(14): freed 35539080 bytes, 6% free (72082808/1073674752), in 1154 ms>… ********************************************… <GC(25): freed 36172752 bytes, 3% free (36172752/1073674752), in 1209 ms>… <GC(26): freed 35313152 bytes, 6% free (71485904/1073674752), in 1186 ms>… <GC(27): freed 1602776 bytes, 0% free (1602776/1073674752), in 934 ms>…1TISIGINFO OUTOFMEMORY received…1TIDATETIME Date: 2005/05/11 at 15:56:13…1TIFILENAME Javacore filename: /bea/user_projects/domains/mydomain/javacore696496.1115798173.txt…1XHTIME Wed May 11 15:56:13 2005…1XHSIGRECV Unexpected signal -1received at 0x0 in <unknown>. Processing terminated.…1XHFULLVERSION J2RE 1.4.2 IBM AIX build ca1420-20040626…2CIUSERARG -Xms1024m…2CIUSERARG -Xmx1024m…2CIUSERARG -verbose:gc…2CIUSERARG -Xverbosegclog:/bea/gc.log…1STHEAPFREE Bytes of Heap Space Free: 45b8 (17,848)…1STHEAPALLOC Bytes of Heap Space Allocated: 3ffefa00 (1,073,674,752)…2LKREGMON Heap lock (0x30071788): owner "ExecuteThread: '0' for queue: 'weblogic.socket.Muxer'" (0x7BA1EC20), entry count 2…3LKWAITERQ Waiting to enter:…3LKWAITER "ExecuteThread: '2' for queue: 'weblogic.kernel.Non-Blocking'" (0x7DF83CA0)…3LKWAITER "ListenThread.Default" (0x7D9D78A0)…3LKWAITER "weblogic.health.CoreHealthMonitor" (0x7C6E3320)…3LKWAITER "Thread-5" (0x7C25BC20)…3LKWAITER "ExecuteThread: '2' for queue: 'weblogic.admin.RMI'" (0x7BD332A0)…3LKWAITER "ExecuteThread: '0' for queue: 'weblogic.admin.RMI'" (0x7BD298A0)…3LKWAITER "ExecuteThread: '2' for queue: 'weblogic.socket.Muxer'" (0x7BA1FEA0)…3LKWAITER "ExecuteThread: '1' for queue: 'weblogic.socket.Muxer'" (0x7BA1F8A0)…3LKWAITER "ExecuteThread: '149' for queue: 'weblogic.kernel.Default'" (0x7B4AE3A0)…3LKWAITER "ExecuteThread: '143' for queue: 'weblogic.kernel.Default'" (0x7B180920)…3LKWAITER "ExecuteThread: '142' for queue: 'weblogic.kernel.Default'" (0x7B0F8F20)…3LKWAITER "ExecuteThread: '128' for queue: 'weblogic.kernel.Default'" (0x7A98E6A0)…3LKWAITER "ExecuteThread: '127' for queue: 'weblogic.kernel.Default'" (0x7A906D20)…3LKWAITER "ExecuteThread: '122' for queue: 'weblogic.kernel.Default'" (0x7A660C20)…3LKWAITER "ExecuteThread: '107' for queue: 'weblogic.kernel.Default'" (0x79E6EA20)…3LKWAITER "ExecuteThread: '100' for queue: 'weblogic.kernel.Default'" (0x79AB6420)…3XMTHREADINFO "ExecuteThread: '81' for queue: 'weblogic.kernel.Default'" (TID:0x30106330, sys_thread_t:0x790A5AA0,state:CW, native ID:0x5B5C) prio=5…4XESTACKTRACE at ng.Object.wait(Native Method)…4XESTACKTRACE at ng.Object.wait(Object.java:443)…4XESTACKTRACE at weblogic.kernel.ExecuteThread.waitForRequest(ExecuteThread.java:153)…4XESTACKTRACE at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:172)…3XMTHREADINFO "ExecuteThread: '98' for queue: 'weblogic.kernel.Default'" (TID:0x30105890, sys_thread_t:0x799A70A0, state:MW, native ID:0x6C6D) prio=5…4XESTACKTRACE at ng.String.substring(String.java(Compiled Code))…4XESTACKTRACE at ng.String.substring(String.java(Compiled Code))…4XESTACKTRACE atweblogic.servlet.internal.WarClassFinder.getSource(WarClassFinder.java(Compiled Code))…4XESTACKTRACE atweblogic.servlet.internal.WebAppServletContext.getSource(WebAppServletContext.java(Compiled Code))…4XESTACKTRACE atweblogic.servlet.internal.WebAppServletContext.getResourceAsSource(WebAppServletContext.java(Compiled Code))…4XESTACKTRACE atweblogic.servlet.internal.WebAppServletContext.getResourceAsSource(WebAppServletContext.java(Compiled Code))…4XESTACKTRACE atweblogic.servlet.internal.WebAppServletContext.isResourceStale(WebAppServletContext.java(Compiled Code))…4XESTACKTRACE at jsp_servlet._feebyowner.__search_result._isStale(__search_result.java(Compiled Code))…4XESTACKTRACE at weblogic.servlet.jsp.JspStub.isServletStale(JspStub.java(Compiled Code))…4XESTACKTRACE at weblogic.servlet.internal.ServletStubImpl.isStale(ServletStubImpl.java(Compiled Code))…4XESTACKTRACE at weblogic.servlet.jsp.JspStub.checkForReload(JspStub.java(Compiled Code))…4XESTACKTRACE atOutOfMemory错误实例(1)其他信息…内存下降太快,陡降!!!又陡升!!!…有报表业务…针对这个报表业务做压力测试,10个用户同时工作,出现OOM!OutOfMemory错误实例(1)分析…用户没有估计到报表业务的内存需求量…用户调整报表业务的实现方式和技术方案OutOfMemory错误实例案例二…环境IBM AIX 5.2,JDK1.4.2,Weblogic Server 813…刚刚启动,运行非常正常…过了一段时间(不定),WLS heap垃圾回收出现异常, <GC(954): mark stackoverflow[190]>,但是从当时的GC日志看,剩余内存还很多。

相关文档
最新文档