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

    检测间隔时间

     等待队列中最多可以有多少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”中等待的线程状态是 “in Object.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: 

事务监控：

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 

请求监控：

DOMAIN -> Deployments  -> Web Application Modules  -> 选择应用  -> Monitoring->Servlets

列表中显示了服务启动以来请求的耗时情况

需要监控的日志：

1、server log

2、access log