《weblogic优化设置&调优参数及监控指标.docx》由会员分享，可在线阅读，更多相关《weblogic优化设置&调优参数及监控指标.docx（11页珍藏版）》请在三一文库上搜索。
1、优化设置Weblogic服务程序设置：1、设置 JDK 内存：修改 weblogicuser_projectsdomainsbase_domainbin下的 setDomainEnv.cmd 文件：修改前：if %JAVA_VENDOR%=Sun (set WLS_MEM_ARGS_64BIT=-Xms256m -Xmx512mset WLS_MEM_ARGS_32BIT=-Xms256m -Xmx512m) else (set WLS_MEM_ARGS_64BIT=-Xms512m -Xmx512mset WLS_MEM_ARGS_32BIT=-Xms512m -Xmx512m)set ME
2、M_PERM_SIZE_32BIT=-XX:PermSize=48mset MEM_MAX_PERM_SIZE_32BIT=-XX:MaxPermSize=128m修改后：if %JAVA_VENDOR%=Sun (set WLS_MEM_ARGS_64BIT=-Xms512m Xmx1024mset WLS_MEM_ARGS_32BIT=-Xms512m Xmx1024m) else (set WLS_MEM_ARGS_64BIT=-Xms1024m Xmx1024mset WLS_MEM_ARGS_32BIT=-Xms1024m Xmx1024m)set MEM_PERM_SIZE_32B
3、IT=-XX:PermSize=128mset MEM_MAX_PERM_SIZE_32BIT=-XX:MaxPermSize=256m说明： 红色字体为修改的内容，具体修改值根据实际物理内存确定? -Xmx3550m ：设置 JVM 最大堆内存 为 3550M 。? -Xms3550m ：设置 JVM 初始堆内存 为 3550M 。此值可以设置与 -Xmx 相同，以避免每次 JVM 动态分配内存所浪费的时间。? -XX:PermSize=256M ：设置 堆内存持久代 初始值为 256M 。 ( 貌似是 Eclipse 等 IDE 的初始化参数 )? -XX:MaxPermSize=512M
4、：设置持久代最大值为 512M 。32 位操作 JDK内存系统：最大可设置1.5G，如果设置过大，会导致服务无法启动64 位操作 JDK内存系统：最大设置为物理内存的6080%2、设置线程数：修改weblogicuser_projectsdomainsbase_domainbin下的setDomainEnv.cmd中在JAVA_OPTIONS中添加如下：set JAVA_OPTIONS=%JAVA_OPTIONS%-Dweblogic.threadpool.MinPoolSize=2000set JAVA_OPTIONS=%JAVA_OPTIONS%-Dweblogic.threadpool.
5、MaxPoolSize=4000说明：JDK5.0 以后每个线程栈大小为1M ，但是操作系统对一个进程内的线程数还是有限制的，不能无限生成。32 位操作系统根据JVM 最大堆内存设置；64 位操作系统经验值在30005000左右。3、 Weblogic 数据库连接池连接数设置：受 Oracle 数据库连接数的影响，可以参照同一时间连接数据库的用户数量，进行设置， 数据库的最大连接数不能小于高峰时期同一时间连接用户的数量。点击数据源，进入后选择连接池：初始容量： 20最大容量： 50容量增长： 5说明：设置前得设置数据库的最大并发线程数（下面有介绍Oracle 数据库线程数设置方法），因为 we
6、blogic 节点的连接池最大连接数之和不能大于数据库的最大线程数。? 初始容量：要在创建连接池时创建的物理连接数。如果无法创建这一数量的连接，创建此连接池的操作将会失败。 此连接数也是连接池将保持的最小可用物理连接数。? 最大容量：此连接池可容纳的最大物理连接数。? 容量增长：将新连接添加到连接池时创建的连接数。不再有可用的物理连接来满足连接请求时， WebLogic Server 会创建该数量的附加物理连接并将它们添加到连接池中。 MBean 属性 ( 不适用于应用程序模块 ) ：JDBCConnectionPoolParamsBean.CapacityIncrement。4、 Weblo
7、gic 的服务设置 配置 优化 ：接受积压： 300登录超时： 5000说明：?接受积压：对于此服务器的常规和 SSL 端口，应该允许的新 TCP 连接请求的积压数量。 将积压设置为 0 可以防止此服务器接受某些操作系统上的所有传入连接。 MBean 属性： ServerMBean.AcceptBacklog 。最小值： 0? 登录超时： 此服务器的默认常规 ( 非 SSL) 监听端口的登录超时。 这是允许建立新连接的最长时间。如果值为0 ，表示无最大值。 MBean 属性：ServerMBean.LoginTimeoutMillis最小值： 0 。最大值： 100000。安全值： 5000w
8、eblogic 调优参数对 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 MaxTi
9、me堵塞线程时间，超过这个时间没有返回的执行线程，系统将认为是堵塞线程如果 weblogic 认为某个队列中的所有的线程全部堵塞的话，weblogic 将会增加执行线程的数量。注意：执行线程的数量一旦增加，目前 weblogic 不会去减少他， 如果增加了一些线程以后再次出现 overflow的警告， weblogic 会继续增加执行线程的数量，一直到达到上限为止。5 、 Stuck Thread Timer Interval系统检查堵塞线程的时间间隔6 、 Low Memory GC Threshold当可用内存小于该百分比时，垃圾回收启动7 、 Low Memory Granularity
10、 Level当两次检测的可用内存变化超过该百分比时，垃圾回收启动8 、 Low Memory Sample Size在一次检测中的取样次数9 、 Low Memory Time Interval检测间隔时间10 、 Accept Backlog等待队列中最多可以有多少TCP连接等待处理，如果在许多客户端连接被拒绝，而在服务器端没有错误显示，说明该值设得过低。如果连接时收到connection refused消息，说明应提高该值，每次增加25二、 ExecuteQueue在mydomain-Servers-myserver-Monitoring-MonitorallActiveQueues.-C
11、onfiguration-weblogic.kernel.Default-1 、 ThreadCount服务器初始创建的执行线程的数量，设置原则：增大机器的最大并发线程数使处理器利用率达到最大。对于服务器端操作比较多的线程，应该减少线程计数； 对于客户端操作比较多的， 应该增加线程计数。 并发线程数理论上等于“本地主机 CPU个数 +Stuck 线程数”，够用即可，过大会降低系统性能2、 QueueLength在等待队列里的请求数，理想状态下是03、 QueueLength Threshold Percent一个百分数， 当 request 的数量达到队列长度的这个比例的时候，weblogic
12、 会发出 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最大数据库物理连
13、接数3 、 Capacity Increment每次数据库物理连接增加数4 、 Statement Cache Typeprepared statements缓存的策略， LRU算法在有新的语句到来时，将最不经常被用得语句调整出缓存。 FIXED算法为先进先出的算法5 、 TestConnectionsOnReserveTestConnectionsOnReserve设置为 false （缺省设置）。如果此参数设置为真（true ），则在连接被分配给调用者之前，都要经过测试，这会额外要求与数据库的反复连接6 、 Statement Cache Size宏语句设定的静态缓存，大小由 JDBC连接
14、池配置时指定，调整这个数值的大小，有利于提高系统的效率7 、 Login Delay创建数据库物理连接时的延时时间weblogic 监控指标线程监控：DOMAIN - 选择服务- Monitoring - General - Monitor all Active Queues. -Monitor all Execute Threads.在这个列表中可以看到应用当前处理的线程情况，若想进一步跟踪线程，可在使用KILL -3 来跟踪查看进程情况，一般情况下线程存在如下状态：A、Runnable ：该状态表示线程具备所有运行条件，在运行队列中准备操作系统的调度，或者正在运行B、 Wait on co
15、ndition：该状态出现在线程等待某个条件的发生1 、线程在等待网络的读写2 、线程在 sleep ，等待 sleep 的时间到了时候，将被唤醒。C、 Waiting for monitor entry和 in Object.wait()：每个 Monitor在某个时刻，只能被一个线程拥有，该线程就是“Active Thread”，而其它线程都是“WaitingThread”，分别在两个队列 “ Entry Set”和“Wait Set ”里面等候。在“Entry Set”中等待的线程状态是“Waiting for monitor entry”，而在“Wait Set ”中等待的线程状态是“
16、inObject.wait() ”。线程为什么会进入“Wait Set ”。当线程获得了Monitor ，进入了临界区之后，如果发现线程继续运行的条件没有满足，它则调用对象（一般就是被synchronized 的对象）的 wait()方法，放弃了 Monitor ，进入 “Wait Set”队列。只有当别的线程在该对象上调用了 notify()或者 notifyAll()， “ Wait Set”队列中线程才得到机会去竞争，但是只有一个线程获得对象的Monitor，恢复到运行态D、死锁：在多线程程序的编写中，如果不适当的运用同步机制，则有可能造成程序的死锁，经常表现为程序的停顿，或者不再响应用
17、户的请求。E、热锁：也往往是导致系统性能瓶颈的主要因素。其表现特征为，由于多个线程对临界区，或者锁的竞争，可能出现：频繁的线程的上下文切换：从操作系统对线程的调度来看，当线程在等待资源而阻塞的时候，操作系统会将之切换出来，放到等待的队列，当线程获得资源之后，调度算法会将这个线程切换进去，放到执行队列中。 大量的系统调用： 因为线程的上下文切换，以及热锁的竞争， 或 者临界区的频繁的进出，都可能导致大量的系统调用。大部分 CPU开销用在 “系统态 ”：线程上下文切换，和系统调用，都会导致CPU在 “系统态 ”运行，换而言之，虽然系统很忙碌，但是CPU用在 “用户态 ”的比例较小，应用程序得不到充
18、分的CPU资源。随着 CPU数目的增多，系统的性能反而下降。因为CPU数目多，同时运行的线程就越多，可能就会造成更频繁的线程上下文切换和系统态的CPU开销，从而导致更糟糕的性能连接监控：DOMAIN - 选择服务- Monitoring - General - Monitor all Connections.性能监控：DOMAIN - 选择服务- Monitoring - Performance1、 Idle Threads：已分配到队列的空闲线程数2、 Oldest Pending Request：被放置在队列中最常的请求所发生的时间3、 Throughput ： The number of
19、 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 res
20、et.3 、 Total Connections:The total number of connections made to this server since the last reset.4 、 Current JMS Servers:Thecurrentnumber of JMS serversthatare deployedon thisWebLogic Serverinstance.5 、 Servers High:Thehighestnumber of JMS serversthatwere deployedon thisWebLogic Serverinstancesince
21、 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 、
22、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
23、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 ApplicationModules-选 择 应 用-Monitoring-Servlets列表中显示了服务启动以来请求的耗时情况需要监控的日志：1、 server log2、 access log