当前位置：文档之家 › weblogic调优参数及监控指标

weblogic调优参数及监控指标

  • 格式：docx
  • 大小：22.25 KB
  • 文档页数：6

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服务器初始创建的执行线程的数量，设置原则：增大机器的最大并发线程数使处理器利用率达到最大。

对于服务器端操作比较多的线程，应该减少线程计数；对于客户端操作比较多的，应该增加线程计数。

并发线程数理论上等于“本地主机CPU个数+Stuck线程数”，够用即可，过大会降低系统性能2、QueueLength在等待队列里的请求数，理想状态下是03、QueueLength Threshold Percent一个百分数，当request的数量达到队列长度的这个比例的时候，weblogic会发出overflow 的标志信息4、ThreadsIncrease如果weblogic发出overflow的标志信息，weblogic会尝试增加这个数量的执行线程，以解决处理矛盾5、ThreadsMaximum最大执行线程数6、Threads Minimum最小执行线程数7、ThreadPriority线程优先级三、JDBC在service->JDBC-> JDBC Connection Pools->Configuration->name->Connections1、 Initial Capacity初始数据库物理连接数2、MaxCapacity最大数据库物理连接数3、Capacity Increment每次数据库物理连接增加数4、Statement Cache Typeprepared statements缓存的策略，LRU算法在有新的语句到来时，将最不经常被用得语句调整出缓存。

FIXED算法为先进先出的算法5、TestConnectionsOnReserveTestConnectionsOnReserve设置为false（缺省设置）。

如果此参数设置为真（true），则在连接被分配给调用者之前，都要经过测试，这会额外要求与数据库的反复连接6、Statement Cache Size宏语句设定的静态缓存，大小由JDBC连接池配置时指定，调整这个数值的大小，有利于提高系统的效率7、Login Delay创建数据库物理连接时的延时时间weblogic监控指标线程监控：DOMAIN -> 选择服务 -> Monitoring -> General -> Monitor all Active Queues... -> Monitor all Execute Threads...在这个列表中可以看到应用当前处理的线程情况，若想进一步跟踪线程，可在使用KILL -3来跟踪查看进程情况，一般情况下线程存在如下状态：A、Runnable：该状态表示线程具备所有运行条件，在运行队列中准备操作系统的调度，或者正在运行B、Wait on condition：该状态出现在线程等待某个条件的发生1、线程在等待网络的读写2、线程在 sleep，等待 sleep的时间到了时候，将被唤醒。

C、Waiting for monitor entry 和in Object.wait()：每个 Monitor在某个时刻，只能被一个线程拥有，该线程就是“Active Thread”，而其它线程都是“Waiting Thread”，分别在两个队列“ Entry Set”和“Wait Set”里面等候。

在“Entry Set”中等待的线程状态是“Waiting for monitor entry”，而在“Wait Set”中等待的线程状态是“inObject.wait()”。

线程为什么会进入“Wait Set”。

当线程获得了 Monitor，进入了临界区之后，如果发现线程继续运行的条件没有满足，它则调用对象（一般就是被 synchronized 的对象）的 wait() 方法，放弃了 Monitor，进入“Wait Set”队列。

只有当别的线程在该对象上调用了 notify() 或者 notifyAll() ，“ Wait Set”队列中线程才得到机会去竞争，但是只有一个线程获得对象的 Monitor，恢复到运行态D、死锁：在多线程程序的编写中，如果不适当的运用同步机制，则有可能造成程序的死锁，经常表现为程序的停顿，或者不再响应用户的请求。

E、热锁：也往往是导致系统性能瓶颈的主要因素。

其表现特征为，由于多个线程对临界区，或者锁的竞争，可能出现：频繁的线程的上下文切换：从操作系统对线程的调度来看，当线程在等待资源而阻塞的时候，操作系统会将之切换出来，放到等待的队列，当线程获得资源之后，调度算法会将这个线程切换进去，放到执行队列中。

大量的系统调用：因为线程的上下文切换，以及热锁的竞争，或者临界区的频繁的进出，都可能导致大量的系统调用。

大部分 CPU开销用在“系统态”：线程上下文切换，和系统调用，都会导致 CPU在“系统态”运行，换而言之，虽然系统很忙碌，但是 CPU用在“用户态”的比例较小，应用程序得不到充分的 CPU资源。

随着 CPU数目的增多，系统的性能反而下降。

因为 CPU数目多，同时运行的线程就越多，可能就会造成更频繁的线程上下文切换和系统态的 CPU开销，从而导致更糟糕的性能连接监控：DOMAIN -> 选择服务 -> Monitoring -> General -> Monitor all Connections...性能监控：DOMAIN -> 选择服务 -> Monitoring -> Performance1、Idle Threads：已分配到队列的空闲线程数2、Oldest Pending Request：被放置在队列中最常的请求所发生的时间3、Throughput：The number of requests that have been processed by the queue4、Queue Length:正在等待的队列5、Memory Usage：当前内存堆栈使用情况6、GC情况消息监控：DOMAIN -> 选择服务 -> Monitoring -> JMS1、Current Connections:The current number of connections to this server.2、Connections High:The highest number of connections to this server since the last reset.3、Total Connections:The total number of connections made to this server since the last reset.4、Current JMS Servers:The current number of JMS servers that are deployed on this WebLogic Server instance.5、Servers High:The highest number of JMS servers that were deployed on this WebLogic Server instance since this server was started.6、Servers Total: 0The total number of JMS servers that were deployed on this WebLogic Server instance since this server was started.事务监控：DOMAIN -> 选择服务 -> Monitoring -> JTA1、Total Transactions: 1641服务处理的事务总数2、Total Committed: 1641提交事务的总数.3、Total Rolled Back: 0回滚事务总数4、Timeout Rollbacks: 0由于超时异常回滚的事务数5、Resource Rollbacks: 0由于资源错误回滚的事务数6、Application Rollbacks: 0由应用回滚的事务数7、System Rollbacks: 0由系统回滚的事务数8、Total Heuristics: 0The total number of transactions that completed with a heuristic status.9、Total Transactions Abandoned: 0The total number of transactions that this server abandoned.10、Active Transaction Count: 0The number of active transactions on the server.11、Average Commit Time: 0 msThe average amount of time (in milliseconds) that transactions coordinated by this server have taken to commit.请求监控：DOMAIN -> Deployments -> Web Application Modules -> 选择应用-> Monitoring->Servlets列表中显示了服务启动以来请求的耗时情况需要监控的日志：1、server log2、access log。

合集下载

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的官方文档。

Weblogic参数调优

Weblogic参数调优

Weblogic参数调优一、调优背景：应银监会总会需求，需对银监会派出机构客户风险监测预警系统进行1轮剔除网络环境的性能测试（在山东试运行阶段的性能测试，由于网络瓶颈较大，造成性能指标较差）。

由于时间紧张，只是匆忙搭建了测试环境，Weblogic、DB2等的参数均是默认设置，并未进行任何调优。

默认设置在系统使用人数不多的情况性能尚可，但当使用人数较多，或者进行大并发的性能测试时，则会显得捉襟见肘。

如：在本次测试过程中，在集团关联处的50并发，就会造成系统崩溃。

如图可见：在集团关联并发50的时候，队列长度已经高达103，空闲线程数已经为0，同时吞吐量极低，由此造成系统崩溃。

通过分析，查找到原因在于：JVM分配内存过少；线程池、连接池里分配的线程数以及容量过低，通过调优后解决了问题二、调优思路：一般来讲，J2EE应用架构环境下的系统调优，首先我们一般会从应用程序出发，去审核代码，做到代码级的优化，然后再调整应用服务器(BEA WebLogic8.1)和数据库(DB2)的参数，最后当然是调整操作系统和网络的性能(包括硬件升级)。

这是一种MDA的先进做法。

诚然，在许多项目中，不可能完全按照这个思路来做，我们把目标首先定位在应用系统所在的应用服务器(BEA WebLogic8.1)上，通过对BEA WebLogic8.1的参数进行设置，使WebLogic8.1能够在最优化的环境中去运行其系统，然后对DB2数据的参数进行优化设置，最后进行性能测试再找出导致性能瓶颈所在的SQL代码或JA V A程序，考量其修改的可行性，并进行最终问题优先级认定，与瓶颈模块进行协商解决性能问题。

当然，大多数时候都出现了性能问题后才想到调优，而且一般都是先进行系统参数调整，实在解决不了才会对代码进行检查。

实际上，我们应当将代码级的调优放在应用设计时来做，测试生产时修改代码将是一件极其痛苦的事情。

而本次测试由于时间紧张，只对Weblogic进行了参数调优，现将调优步骤进行说明：1．JVM调整：(1)首先，在D:\bea\user_projects\domains\mydomain下用编译模式打开startWebLogic.cmd，查找代码：call "%WL_HOME%\common\bin\commEnv.cmd"(windows)或者call "%WL_HOME%\common\bin\commEnv.sh"(linux/aix)找到后，在相应路径用编译模式打开该文件：(2)接着要弄清楚JDK厂商（是bea，还是sun、IBM等）set JA V A_VENDOR=BEA（此处说明应用的为BEA的JDK）(3)之后查找weblgoic运行模式：set PRODUCTION_MODE=默认是开发模式（线程计数默认为15）即为空，在上线时，应将其改为产品模式（线程计数默认为25）：set PRODUCTION_MODE=ture(4)然后需修改分配给JVM的内存（默认为96M）：因已确定厂商为BEA，运行模式为产品模式，所以找到：:beaif "%PRODUCTION_MODE%" == "true" goto bea_prod_modeset JA V A_VM=-jrockitset MEM_ARGS=-Xms1024m -Xmx1024mset JA V A_OPTIONS=%JA V A_OPTIONS% -Xverify:nonegoto continue:bea_prod_modeset JA V A_VM=-jrockitset MEM_ARGS=-Xms1024m -Xmx1024m（此处即为分配给JVM的内存范围）goto continue可根据系统需要，修改分配的内存数注：如为32位的操作系统，则最大支持分配2G内存2．线程池调整：打开Weblogic，在路径：mydomain->服务器->myserver->右键打开“查看执行队列” weblogic.kernel.Default调整如下指标：(1) 线程计数—分配给此队列的线程数，建议值为: 100(2) 线程数增加—在出现溢出时，要添加到队列中的线程数，建议值为: 50(3) 最大线程数—此队列可以拥有的最大线程数。

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。

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处理进程内存溢出报错，导致服务器宕机。