weblogic调优参数及监控指标.docx

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”中等待的线程状态是 “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 - 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 - 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: 0 The 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