weblogic调优参数及监控指标

亚瑟王 亚瑟王 2022-04-26 367 Java

weblogic调优参数

对Weblogic的调优主要从SEVER、ExecuteQueue、JDBC等几个方面的相关参数进行调优:

一、SERVER

在mydomain->Servers->myserver->Configuration->Tuning->“Enable Native IO”中:

1、Native IOEnabled

TRUE,表示该Server使用本地I/O

2、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

在等待队列里的请求数,理想状态下是0

3、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->Connections

1、 Initial Capacity

初始数据库物理连接数

2、MaxCapacity

最大数据库物理连接数

3、Capacity Increment

每次数据库物理连接增加数

4、Statement Cache Type

prepared statements缓存的策略,LRU算法在有新的语句到来时,将最不经常被用得语句调整出缓存。FIXED算法为先进先出的算法5、TestConnectionsOnReserve TestConnectionsOnReserve设置为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 -> Performance

1、Idle Threads:已分配到队列的空闲线程数

2、Oldest Pending Request:被放置在队列中最常的请求所发生的时间

3、Throughput:The number of requests that have been processed by the queue

4、Queue Length:正在等待的队列

5、Memory Usage:当前内存堆栈使用情况

6、GC情况

消息监控:

DOMAIN -> 选择服务

-> Monitoring -> JMS

1、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 -> JTA

1、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: 0

The total number of transactions that completed with a heuristic status.

9、Total Transactions Abandoned: 0

The total number of transactions that this server abandoned.

10、Active Transaction Count: 0

The number of active transactions on the server.

11、Average Commit Time: 0 ms

The 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 log

2、access log

【下载地址】

百度网盘链接:https://pan.baidu.com/s/1LPJdsVR15IaXAkL5-9TqyQ

提取码:6nec


相关文章


使用-JFreeChart来创建基于web的图表

使用-JFreeChart来创建基于web的图表

XStream使用文档

XStream使用文档

WebService发布过程及常见问题

WebService发布过程及常见问题

webpack实战入门进阶调优分享

webpack实战入门进阶调优分享

weblogic调优参数及监控指标

weblogic调优参数及监控指标

weblogic节点管理

weblogic节点管理

weblogic管理控制台概述

weblogic管理控制台概述

weblogic-部署和启动

weblogic-部署和启动

WebLogic-Server-性能及调优-调优-Java-虚拟机

Java 虚拟机(Java virtual machine,简称 JVM)是一种虚拟“执行引擎”实例,可在微处理器上执行 Java 类文件中的字节码。调整 JVM 的方式会影响 Weblogic Server 和应用程序的性能。

Velocity用户教程

Velocity是一个基于java的模板引擎(template engine)。它允许任何人仅仅简单的使用模板语言(template language)来引用由java代码定义的对象。

Velocity用户手册

Velocity 用户手册是帮助页面设计者和内容提供者认识 Velocity 和其简单而功能强大的脚本语言――Velocity 模板语言(VTL)。在手册上的许多例子,都是用 Velocity 插入动态的内容到网页上,但是所有的 VLT 例子都能应用到其他的页面和模板中。

知之

知之平台是全球领先的知识付费平台。提供各个领域的项目实战经验分享,提供优质的行业解决方案信息,来帮助您的工作和学习

使用指南 建议意见 用户协议 友情链接 隐私政策 Powered by NOOU ©2020 知之