weblogic12.2.1线程池监控指标说明

1、weblogic版本为12.2.1最新版本

2、在进入环境->服务器->监视->线程池后，我们可以看到weblogic关于线程池监控的一些默认指标，如图所示：

 

1、活动执行线程: 池中的活动执行线程数。（可在config.xml下进行配置）配置方法为：

<server>

    <name>AdminServer</name>

    <self-tuning-thread-pool-size-min>10</self-tuning-thread-pool-size-min>

    <self-tuning-thread-pool-size-max>20</self-tuning-thread-pool-size-ma>

  </server>

2、空闲执行线程：池中的空闲线程数。此计数不包含待机线程数和阻塞线程数。该计数表示新工作到达时准备好采用该工作的线程数。

3、暂挂请求：优先级队列中的暂挂用户请求数。优先级队列包含来自内部子系统和用户的请求。这只是所有用户请求的计数。

4、完成的请求：优先级队列中完成的请求数。

5、独占线程数：请求现在所保留的线程。这些线程将在配置的超时过后被声明为阻塞或在超时结束前返回给池。自优化机制将在必要时进行回填。

6、备用线程数：备用池中的线程数。处理当前工作负载所不需要的线程将被指定为备用线程并会添加到备用池中。需要更多线程时将激活这些线程。

7、阻塞线程：线程池中的阻塞线程数。

8、吞吐量：每秒平均完成的请求数（具体为最近几秒尚不是清楚）

9、健康状况：此池的健康状况。（正常、警告、超载、严重、失败）

weblogic支持定制表单，可以对显示的指标项进行自定义：

非默认指标的含义：

使拒绝的请求超载：由于已达到为工作管理器配置的共享容量而拒绝的请求数。

工作管理器的共享空间：优先级队列中可以接受的最大请求数。请注意，即使在达到阈值后，优先级较高的请求仍将被接受，并且会替代队列中已有的优先级较低的请求。优先级较低的请求在队列中保持等待状态，直到所有高优先级请求都执行完毕。另请注意，当有更多低优先级请求入队时，会立刻被拒绝。

已完成的最小线程数约束条件：因未能满足最低线程要求而以无序方式挑出的具有最低线程约束条件的请求数。它不包括调度期间线程空闲的情况。

已挂起：指示 RequestManager 是否挂起。挂起的管理器在恢复后才能使工作离开队列和分派线程。

执行线程总数：池中的总线程数。

暂挂的最小线程数约束条件：应立即执行以满足最低线程要求的请求数。

队列长度：优先级队列中的暂挂请求数。这是内部系统请求和用户请求的总数。

 

一些指标之间的关系：

1.活动的线程数包含空闲的线程数和正在执行的线程数，正在执行的线程数又包含粘滞的线程数和独占的线程数和正常执行的线程数。

2.总的线程数包含活动的线程数和备用的线程数。

3.粘滞的线程和独占的线程在执行完成后变为备用线程。

4.备用线程：处理当前工作负载所不需要的线程将被指定为备用线程并会添加到备用池中，需要更多线程时将激活这些线程。

 

线程阻塞性能调优：

声明：出现这个问题有程序方面、网络方面、weblogic设置方面等等原因，此文章主要讲述由于weblogic设置而导致的解决办法。

因为：

1.程序问题，需要项目自己去解决，weblogic在做优化处理也于事无补。

2.网络中断或者认为关闭交互这种情况也不能用weblogic处理（这点我是这么认为的）

一、说明：

,"weblogic.kernel.Default"是从客户端提交请求后产生的线程所在的队列名。这个队列的线程数默认是15个。如果超过15个线程堵塞，则部署的应用将不能访问。同时后台报：
<2008-2-27 下午09时37分48秒 CST> <Error> <WebLogicServer> <BEA-000337> <ExecuteThread: '14' for queue: 'weblogic.kernel.Default' has been busy for "1,720" seconds working on the request "Http Request: /myapp/test/index.jsp", which is more than the configured time (StuckThreadMaxTime) of "600" seconds.> 
2，线程数(Tread Count)：指派到weblogic.kernel.Default队列的线程数。如果你不需要使用超过15个线程（默认），就不必更改这个属性值。
 

 如果发送该请求较多，很有可能会导致weblogic的线程阻塞，严重会引起weblogic挂起现象。
可以通过以下几种方法解决： 
1）修改StuckThreadMaxTime参数，将默认的600s改成1200s，或者其它适合的值。
2）增大线程数，防止线程阻塞问题。
3）优化程序，减少处理时间。

二、修改办法

------------------------------------↓↓↓↓↓↓↓↓↓↓修改办法↓↓↓↓↓↓↓↓↓--------------------------

1） 如何修改StuckThreadMaxTime参数值：http://lujinan858.iteye.com/blog/986237

启动weblogic服务，进入控制台：

your_domain->Environment->Servers->your_server->Configuration->Tuning->Stuck Thread Max Time

如下图：

2）怎样增大线程数

window环境下修改【bea】\user_projects\domains\my_domain\bin\setDomainEnv.cmd文件，查询最下面set JAVA_OPTIONS=%JAVA_OPTIONS%

改为：

set JAVA_OPTIONS=%JAVA_OPTIONS% -Dweblogic.threadpool.MinPoolSize=50
set JAVA_OPTIONS=%JAVA_OPTIONS% -Dweblogic.threadpool.MaxPoolSize=300

Window环境下设置完应该直接重新启动就可以生效，Linux下，有可能会出现以下错误：

Attempting to allocate 4G bytes

There is insufficient native memory for the Java
Runtime Environment to continue.

Possible reasons:
  The system is out of physical RAM or swap space
  In 32 bit mode, the process size limit was hit

Possible solutions:
  Reduce memory load on the system
  Increase physical memory or swap space
  Check if swap backing store is full
  Use 64 bit Java on a 64 bit OS
  Decrease Java heap size (-Xmx/-Xms)
  Decrease number of Java threads
  Decrease Java thread stack sizes (-Xss)
  Disable compressed references (-XXcompressedRefs=false)

java.lang.OutOfMemoryError: Resource temporarily unavailable in tsStartJavaThread (lifecycle.c:1097).

Attempting to allocate 4G bytes

There is insufficient native memory for the Java
Runtime Environment to continue.

Possible reasons:
  The system is out of physical RAM or swap space
  In 32 bit mode, the process size limit was hit

Possible solutions:
  Reduce memory load on the system
  Increase physical memory or swap space
  Check if swap backing store is full
  Use 64 bit Java on a 64 bit OS
  Decrease Java heap size (-Xmx/-Xms)
  Decrease number of Java threads
  Decrease Java thread stack sizes (-Xss)
  Disable compressed references (-XXcompressedRefs=false)

 

出现这个原因的问题可能是因为Linux下系统对用户的默认线程数做了限制，可以通过：

ulimit -a

 

命令进行查看：

core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 515223
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 1024
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

 

其中

max user processes              (-u) 1024

 

表示当前系统允许的最大线程数，可以把此参数设大一些。

ulimit -u 5000

 

设置当前系统用户最大允许的线程数，只对本次会话有效，如果想要永久生效，可以通过修改：

$ cat /etc/security/limits.d/90-nproc.conf 
# Default limit for number of user's processes to prevent
# accidental fork bombs.
# See rhbz #432903 for reasoning.

*          soft    nproc    1024

 

只需要将1024改成你需要的值即可，设置完需要重启系统已生效。

 

一、背景 
项目月底请求并发量大，查看控制台，线程出现大量积压，响应时间增加。在LoadRunner压1000并发下，发现应用表现并不好，响应时间明显增加。

二、分析 
监控服务器资源，发现集群平台服务器负载并不高，而web应用服务器负载同样也不高，服务器性能并没达到瓶颈。进入weblogic控制台，查看线程池，发现在压1000并发的时候，请求积压队列明显较多，而线程数只有50左右。说明一下，weblogic产品模式下，默认初始线程数为25，开发模式下好像是15，weblogic11g采用的是自调整线程池，看名字就可以猜出，他会根据应用情况自动增加减少线程数，而实际情况下，在压力增大的情况下，weblogic也确实增加了线程数，但是增加的线程数不足以应付该需求，于是自然而然地想到了增加线程数。

三、解决 
weblogic11g已经不支持在控制台修改线程数，只能通过配置文件，网上有朋友说可以通过增加weblogic启动参数来配置线程数: 
-Dweblogic.threadpool.MinPoolSize=100 
-Dweblogic.threadpool.MaxPoolSize=500 
该方法经试验，并不能生效，还好还一种方法，修改域下面conf里面的config.xml文件： 
<server> 
<name>AdminServer</name> 
<self-tuning-thread-pool-size-min>400</self-tuning-thread-pool-size-min> 
<self-tuning-thread-pool-size-max>400</self-tuning-thread-pool-size-max> 
<listen-address/> 
</server> 
在这里把线程数最大值最小值都设成了400，400这个数值不是乱设的，WebLogic可以近乎线性地提高线程数。线程数越多，花费在线程切换的时间也就越多；线程数越小，CPU可能无法得到充分的利用。为获取一个理想的线程数，需要经过反复的测试。一般来说一个CPU最好小于50个线程数（注：笔者刚才发现之前我把CPU数当成了核心数，笔者用的服务器是24核，所以当时理所当然认为设置1000个线程数也是ok的）。最开始使用1000线程数做测试，因为最大并发数是1000，笔者想象来一个请求就给一个线程处理，没有请求排队，实际上确实如此，但是把线程数调低后，发现即使有排队情况出现，但响应时间却比之前1000线程要快，为什么会出现这种情况呢？原来还有一点我们忘记了，数据库连接池。数据库连接池也是影响性能的指标之一，想想应用1000个请求过来，但是数据库连接数不够，在数据库这边排队，还是会影响整体性能表现，所以如何配置weblogic线程数以及数据库连接线程数使整体性能达到最优，这需要再仔细测试，如果数据库连接数也能设置到1000，我想应该这是一个比较理想的设置，但很多情况下根据平台不同，不可能这么简单，过高的连接数总会占用过多系统资源，引发GC等一系列问题。笔者的应用根据多次测试，把数据库连接跟线程数设置成了一样的，都是400，这肯定不是最优的，但应该算是性能表现比较满意的一组值。

四、总结 
1、出现性能瓶颈时，先找出现瓶颈的地方，是应用服务器还是数据库服务器 
2、判断是否需要修改weblogic线程数以及数据库连接池的值 
3、多次测试，得出一组合适的weblogic线程数的值以及数据库连接数的值