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

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

并发线程数理论上等于“本地主机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。