关于weblogic性能监控.docx
《关于weblogic性能监控.docx》由会员分享，可在线阅读，更多相关《关于weblogic性能监控.docx（16页珍藏版）》请在冰豆网上搜索。
关于weblogic性能监控
关于weblogic性能监控
2013年5月
目录
1.部署结构3
1.1.简介3
1.2.常见可能原因3
2.Weblogic优化设置4
2.1.设置JDK内存：
4
2.2.设置线程数6
2.3.Weblogic数据库连接池连接数设置6
2.4.Weblogic的服务设置[配置\优化]7
3.Windows服务器设置7
3.1.修改最高端口号和TCP/IP释放连接时间7
4.Oracle数据库设置8
4.1.Oracle线程数设置8
5.查看使用哪种JVM8
5.1.SunJVM8
5.2.OracleJRockitJVM9
5.3.VisualVM9
5.4.VisualVM详细参数13
1.部署结构
1.1.简介
根据了解到现场的情况，大概的部署结构如下：
其中第二章、第三章、第四章所列的内容有几项已经尝试过，所以具体的指标需要再根据后边的调控性能进行监控后再做出相应的调整。
1.2.常见可能原因
性能低下可能有许多原因。
下面是一些可能造成应用程序性能低下的最为常见的问题：
内存泄漏。
内存泄漏这个术语有点误导。
尽管您的计算机或JVM中的内存不会象水一样“泄漏”，但随着时间的流逝，您会注意到可用内存会比预期的少。
既然JVM垃圾回收器（GC）通过从内存中删除不使用的对象来收回不使用的内存，为何还会出现这种情况？
这很可能是因为，有些可从内存中删除的对象因其没有表现为未使用而不能被GC所发现。
大多数的内存泄漏是由于被遗漏的引用或实现不良的自生缓存而引起。
（提示：
如果您不使用软引用或弱引用，就不能利用GC来自动缩减缓存。
）这些泄漏会增加GC的调用次数及其发现要释放的少量内存所需的时间。
这样导致的应用程序开销会影响用户的体验。
找出并消除这些内存泄漏的情况是性能调优的主要目标。
数据建模不良。
数据建模对应用程序的运行时行为有极大的影响。
我们应该知道，在现代的多层应用程序中，数据能够并且会跨越进程边界。
跨越这些边界需要花费时间，因为须将二进制形式的数据转换为一种传输格式。
然而，随着这种序列化和反序列化过程的实现，比起数据待在进程内的情况，程序速度变得更慢了。
所使用的数据类型以及实现该过程的方式对整体性能有着极大的影响。
例如，日期或时间戳通常保存为64位的值（Java的Long类型）。
然而，选择用Calendar类型来保存此类信息也没有问题。
Calendar类型一般会占用80个字节。
因此，通过选用合适的类型来保存时间戳信息，可以轻松节省72个字节。
另外，相比于非序列化，选择外化可极大地提高性能。
缺点是外化会为开发期间高度紧迫的编程实践带来额外的成本开销。
网络输入/输出流量较高有关网络计算的一个谬论是，“快速的”网络。
一旦您需要进行远程调用，那么绝对会更为费时。
减少网络调用的次数或大小都可节省应用程序所需时间以供他用。
节省网络时间相当容易。
其中一个方法是，让远程应用程序完成自己的工作。
一般来说，非常具体的调用只返回一个正确结果，与那些返回数千个不需要的结果的调用相比，显然更为快速。
JVM配置不良。
每个JVM都可通过许多命令行开关来配置，其中许多开关会直接或间接地影响应用程序的运行时行为。
例如，几乎每个JVM用户都知道用于定义JVM内存大小（或称为“堆”）的开关。
而其他开关不太为人所熟知，但恰当地设置这些开关，可以在特定的使用情况配置文件环境下提高性能；然而，在另一个不同的使用情况配置文件环境下，同样的设置也可能会降低性能。
数据库速度慢。
在一个多层架构中，数据库速度慢是一个不当托词。
相反，在应用程序架构的庞大组织中，数据库几乎总是速度最快的那部分。
另一方面，缺失索引可极大地降低性能。
数据库经过充分调优，SQL语句使用恰当，这两者一起有助于实现最佳的架构。
2.Weblogic优化设置
2.1.设置JDK内存：
修改weblogic\user_projects\domains\base_domain\bin下的setDomainEnv.cmd文件：
修改前：
if"%JAVA_VENDOR%"=="Sun"（
setWLS_MEM_ARGS_64BIT=-Xms256m-Xmx512m
setWLS_MEM_ARGS_32BIT=-Xms256m-Xmx512m
）else（
setWLS_MEM_ARGS_64BIT=-Xms512m-Xmx512m
setWLS_MEM_ARGS_32BIT=-Xms512m-Xmx512m
）
setMEM_PERM_SIZE_32BIT=-XX:
PermSize=48m
setMEM_MAX_PERM_SIZE_32BIT=-XX:
MaxPermSize=128m
修改后：
if"%JAVA_VENDOR%"=="Sun"（
setWLS_MEM_ARGS_64BIT=-Xms512m–Xmx1024m
setWLS_MEM_ARGS_32BIT=-Xms512m–Xmx1024m
）else（
setWLS_MEM_ARGS_64BIT=-Xms1024m–Xmx1024m
setWLS_MEM_ARGS_32BIT=-Xms1024m–Xmx1024m
）
setMEM_PERM_SIZE_32BIT=-XX:
PermSize=128m
setMEM_MAX_PERM_SIZE_32BIT=-XX:
MaxPermSize=256m
说明：
红色字体为修改的内容，具体修改值根据实际物理内存确定
∙-Xmx3550m：
设置JVM最大堆内存为3550M。
∙-Xms3550m：
设置JVM初始堆内存为3550M。
此值可以设置与-Xmx相同，以避免每次JVM动态分配内存所浪费的时间。
∙-XX:
PermSize=256M：
设置堆内存持久代初始值为256M。
（貌似是Eclipse等IDE的初始化参数）
∙-XX:
MaxPermSize=512M：
设置持久代最大值为512M。
32位操作JDK内存系统：
最大可设置1.5G，如果设置过大，会导致服务无法启动
64位操作JDK内存系统：
最大设置为物理内存的60~80%
2.2.设置线程数
修改weblogic\user_projects\domains\base_domain\bin下的setDomainEnv.cmd中在JAVA_OPTIONS中添加如下：
setJAVA_OPTIONS=%JAVA_OPTIONS%-Dweblogic.threadpool.MinPoolSize=2000
setJAVA_OPTIONS=%JAVA_OPTIONS%-Dweblogic.threadpool.MaxPoolSize=4000
说明：
JDK5.0以后每个线程栈大小为1M，但是操作系统对一个进程内的线程数还是有限制的，不能无限生成。
32位操作系统根据JVM最大堆内存设置；64位操作系统经验值在3000~5000左右。
2.3.Weblogic数据库连接池连接数设置
受Oracle数据库连接数的影响，可以参照同一时间连接数据库的用户数量，进行设置，数据库的最大连接数不能小于高峰时期同一时间连接用户的数量。
点击数据源，进入后选择连接池：
初始容量：
20
最大容量：
50
容量增长：
5
说明：
设置前得设置数据库的最大并发线程数（下面有介绍Oracle数据库线程数设置方法），因为weblogic节点的连接池最大连接数之和不能大于数据库的最大线程数。
∙初始容量：
要在创建连接池时创建的物理连接数。
如果无法创建这一数量的连接，创建此连接池的操作将会失败。
此连接数也是连接池将保持的最小可用物理连接数。
∙最大容量：
此连接池可容纳的最大物理连接数。
∙容量增长：
将新连接添加到连接池时创建的连接数。
不再有可用的物理连接来满足连接请求时，WebLogicServer会创建该数量的附加物理连接并将它们添加到连接池中。
MBean属性（不适用于应用程序模块）：
JDBCConnectionPoolParamsBean.CapacityIncrement。
2.4.Weblogic的服务设置[配置\优化]
接受积压：
300
登录超时：
5000
说明：
∙接受积压：
对于此服务器的常规和SSL端口，应该允许的新TCP连接请求的积压数量。
将积压设置为0可以防止此服务器接受某些操作系统上的所有传入连接。
MBean属性：
ServerMBean.AcceptBacklog。
最小值：
0
∙登录超时：
此服务器的默认常规（非SSL）监听端口的登录超时。
这是允许建立新连接的最长时间。
如果值为0，表示无最大值。
MBean属性：
ServerMBean.LoginTimeoutMillis最小值：
0。
最大值：
100000。
安全值：
5000
3.Windows服务器设置
3.1.修改最高端口号和TCP/IP释放连接时间
在注册表HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlset\Services\Tcpip\Parameters下加入新建值：
MaxUserPort，（DWORD值）十进制，65534
TcpTimedWaitDelay，（DWORD值）十进制，30
说明：
同时使用这两个参数，集群时Windows服务器一定要设置。
∙MaxUserPort：
确定在应用程序从系统请求可用用户端口时，TCP/IP可指定的最高端口号。
缺省值：
无。
建议值：
十进制65534。
∙TcpTimedWaitDelay：
减少此条目的值允许TCP/IP更快地释放已关闭的连接，为新连接提供更多资源。
如果运行的应用程序需要快速释放和创建新连接，而且由于TIME_WAIT中存在很多连接，导致低吞吐量，则调整此参数。
缺省值：
240，它将等待时间设置为240秒（4分钟）。
建议值：
设置为30秒。
停止并重新启动系统。
4.Oracle数据库设置
4.1.Oracle线程数设置
通过设置以下语句查询和设置Oracle的线程数：
--查询最大线程连接数：
showparameterprocesses
--更改线程连接数：
altersystemsetprocesses=500scope=spfile;
设置完成后重启数据库。
启动后通过查询最大线程连接数（showparameterprocesses）查看是否设置正确并生效。
说明：
默认是150个，这个量并非越大越好，需要根据硬件性能来设置。
5.查看使用哪种JVM
5.1.SunJVM
SunJVM是Java参考实现，应该用它来验证应用程序是否按照预期运行。
SunJVM的内存模型包含两个主要的内存区域：
年轻代和年老代。
年轻代区域又分为一个Eden空间和两个存活空间。
另外，还有一个可用的持久代（PermGenSpace）。
动态创建的对象开始时存放于EdenSpace中。
在垃圾回收期间，这些对象移至存活空间然后再移至年老代，直到它们因未被使用而被GC回收。
PermGenSpace存储静态数据，如类、常量值和静态变量。
如果PermGenSpace很小，其中却加载了过多的类、静态变量和常量值，SunJVM可能很快就会用光内存。
由于PermGenSpace是从整体堆容量中获取其空间的，其空间一定相当小。
当年老代持续占用可用空间的70-80%时，我们就可以认为发生了内存泄漏。
而当占用了90%时，情况就非常严重了，应立即进行分析。
高度饱和的内存使用会影响运行时，因为此时对GC的调用会更为频繁并且GC需要更长的周期时间才能找到可回收的区域。
这些区域通常过小，GC需要更多的周期来完成内存请求。
当情况变得越来越糟时，JVM只能执行GC，因而应用程序挂起。
SunJVM附带有各种GC。
每种GC对于特定的使用情况配置文件来说都是完美的。
有关可用GC的详细信息，可参阅JVM文档。
可通过命令行开关来调优GC及其行为。
5.2.OracleJRockitJVM
OracleJRockitJVM是一个Java兼容实现，其设计旨在实现针对Intel硬件的非常快速的JVM。
JRockit的内存模型类似于SunJVM的内存模型，它也有年轻代和年老代区域。
新对象和存活时间尚短的对象存放于年轻代区域中，而存活时间较长的对象可存放于年老代区域中。
OracleJRockit内存模型没有PermGenSpace，因此不会因PermGenSpace饱和而引发任何内存不足之异常情况。
OracleJRockitJVM同样提供各种GC。
特别是为了获得更佳的运行时行为，值得尝试并发标记扫描GC和并行标记扫描GC。
就SunJVM而言，这些GC可通过命令行开关来明确地设置，并且它们是应用程序使用情况配置文件的优化配置中的一部分设置。
5.3.VisualVM
关于介绍什么的可以参考网上的一些文档，主要是监控java的运行情况。
下面主要写一下如何监控远程的weblogic以及看哪些参数。
每个分析均从VisualVM控制台开始。
这会以非常整洁的方式显示所有运行时参数（无需挖掘某些启动脚本）。
只需单击Monitor选项卡即可显示JVM的当前状态。
到服务器的JDk安装目录的bin目录下，也可以在本机使用，找到jvisualvm.exe，双击运行。
双击local下的可以看到本地的情况。
在远程连接的情况，需要在weblogic所在的服务器上配置，找到domain目录下的startWebLogic.cmd，然后在里边添加如下红色部分
@ECHOOFF
@REMWARNING:
ThisfileiscreatedbytheConfigurationWizard.
@REMAnychangestothisscriptmaybelostwhenaddingextensionstothisconfiguration.
SETLOCAL
setJAVA_OPTIONS=-Dcom.sun.management.jmxremote.port=1090-Dcom.sun.management.jmxremote.ssl=false-Dcom.sun.management.jmxremote.authenticate=false-Dcom.sun.management.builder.initial=weblogic.management.jmx.mbeanserver.WLSMBeanServerBuilder
setDOMAIN_HOME=C:
\Oracle\Middleware\user_projects\domains\base_domain
call"%DOMAIN_HOME%\bin\startWebLogic.cmd"%*
ENDLOCAL
然后启动weblogic，回到visualVM。
点remote，右键，addremotehost…，输入服务器的IP
然后点击AddJMXConnection…，可以显示服务器端运行的参数情况。
本地的可能为英文也可能为中文。
以下截图供参考：
在概述标签中，描述了该应用的类型，进程号，IP地址，JVM内存大小设置情况，以及启动参数等，也可看到应用路径，如：
webapp.root=/home/peuser/pe/run/jboss/./tmp/deploy/tmp61754843639786460pe-1.0-SNAPSHOT-exp.war
此处了解即可。
JVM内容总览，可从上图各图形中看到当前CPU、堆栈、PerGen空间使用以及对象和线程的活动情况。
如果PerGen不断增加,超过JVM中设置的PerGenSize，可能会导致内存溢出情况。
如果发现此处有问题，则需要进一步分析，分析方法在发现问题后再详细列出。
可以具体监控比如CPU、内存还是内部的问题，然后再向下分析。
5.4.VisualVM详细参数
性能分析的主要方式
监视：
监视是一种用来查看应用程序运行时行为的一般方法。
通常会有多个视图（View）分别实时地显示CPU使用情况、内存使用情况、线程状态以及其他一些有用的信息，以便用户能很快地发现问题的关键所在。
转储：
性能分析工具从内存中获得当前状态数据并存储到文件用于静态的性能分析。
Java程序是通过在启动Java程序时添加适当的条件参数来触发转储操作的。
它包括以下三种：
系统转储：
JVM生成的本地系统的转储，又称作核心转储。
一般的，系统转储数据量大，需要平台相关的工具去分析，如Windows上的windbg和Linux上的gdb。
Java转储：
JVM内部生成的格式化后的数据，包括线程信息，类的加载信息以及堆的统计数据。
通常也用于检测死锁。
堆转储：
JVM将所有对象的堆内容存储到文件。
快照：
应用程序启动后，性能分析工具开始收集各种运行时数据，其中一些数据直接显示在监视视图中，而另外大部分数据被保存在内部，直到用户要求获取快照，基于这些保存的数据的统计信息才被显示出来。
快照包含了应用程序在一段时间内的执行信息，通常有CPU快照和内存快照两种类型。
CPU快照：
主要包含了应用程序中函数的调用关系及运行时间，这些信息通常可以在CPU快照视图中进行查看。
内存快照：
主要包含了内存的分配和使用情况、载入的所有类、存在的对象信息及对象间的引用关系等。
这些信息通常可以在内存快照视图中进行查看。
性能分析：
性能分析是通过收集程序运行时的执行数据来帮助开发人员定位程序需要被优化的部分，从而提高程序的运行速度或是内存使用效率，主要有以下三个方面：
CPU性能分析：
CPU性能分析的主要目的是统计函数的调用情况及执行时间，或者更简单的情况就是统计应用程序的CPU使用情况。
通常有CPU监视和CPU快照两种方式来显示CPU性能分析结果。
内存性能分析：
内存性能分析的主要目的是通过统计内存使用情况检测可能存在的内存泄露问题及确定优化内存使用的方向。
通常有内存监视和内存快照两种方式来显示内存性能分析结果。
线程性能分析：
线程性能分析主要用于在多线程应用程序中确定内存的问题所在。
一般包括线程的状态变化情况，死锁情况和某个线程在线程生命期内状态的分布情况等
为visualVM添加插件：
•从主菜单中选择“工具”>“插件”。
•在“可用插件”标签中，选中该插件的“安装”复选框。
单击“安装”。
•逐步完成插件安装程序。
内存分析
VisualVM通过检测JVM中加载的类和对象信息等帮助我们分析内存使用情况，我们可以通过VisualVM的监视标签和Profiler标签对应用程序进行内存分析。
在监视标签内，我们可以看到实时的应用程序内存堆以及永久保留区域的使用情况。
内存堆使用情况
永久保留区域使用情况
此外，我们也可以通过Applications窗口右击应用程序节点来启用“在出现OOME时生成堆Dump”功能，当应用程序出现OutOfMemory例外时，VisualVM将自动生成一个堆转储。
开启“在出现OOME时生成堆”功能
在Profiler标签，点击“内存”按钮将启动一个内存分析会话，等VisualVM收集和统计完相关性能数据信息，将会显示在性能分析结果。
通过内存性能分析结果，我们可以查看哪些对象占用了较多的内存，存活的时间比较长等，以便做进一步的优化。
此外，我们可以通过性能分析结果下方的类名过滤器对分析结果进行过滤。
内存分析结果
CPU分析
VisualVM能够监控应用程序在一段时间的CPU的使用情况，显示CPU的使用率、方法的执行效率和频率等相关数据帮助我们发现应用程序的性能瓶颈。
我们可以通过VisualVM的监视标签和Profiler标签对应用程序进行CPU性能分析。
在监视标签内，我们可以查看CPU的使用率以及垃圾回收活动对性能的影响。
过高的CPU使用率可能是由于我们的项目中存在低效的代码，可以通过Profiler标签的CPU性能分析功能进行详细的分析。
如果垃圾回收活动过于频繁，占用了较高的CPU资源，可能是由内存不足或者是新生代和旧生代分配不合理导致的等。
CPU使用情况
在Profiler标签，点击“CPU”按钮启动一个CPU性能分析会话,VisualVM会检测应用程序所有的被调用的方法。
当进入一个方法时，线程会发出一个“methodentry”的事件，当退出方法时同样会发出一个“methodexit”的事件，这些事件都包含了时间戳。
然后VisualVM会把每个被调用方法的总的执行时间和调用的次数按照运行时长展示出来。
此外，我们也可以通过性能分析结果下方的方法名过滤器对分析结果进行过滤。
CPU性能分析结果
线程分析
Java语言能够很好的实现多线程应用程序。
当我们对一个多线程应用程序进行调试或者开发后期做性能调优的时候，往往需要了解当前程序中所有线程的运行状态，是否有死锁、热锁等情况的发生，从而分析系统可能存在的问题。
在VisualVM的监视标签内，我们可以查看当前应用程序中所有活动线程和守护线程的数量等实时信息。
活跃线程情况
VisualVM的线程标签提供了三种视图，默认会以时间线的方式展现。
另外两种视图分别是表视图和详细信息视图。
时间线视图上方的工具栏提供了缩小，放大和自适应三个按钮，以及一个下拉框，我们可以选择将所有线程、活动线程或者完成的线程显示在视图中。
线程时间线视图
线程表视图
我们在详细信息视图中不但可以查看所有线程、活动线程和结束的线程的详细数据，而且也可以查看某个线程的详细情况。
线程详细视图
升级会员 