Jprofiler内存监控及系统调优.ppt

性能测试——内存泄露 2.打开Jprofiler的Memory views界面（初始界面） 打开Recorded Object标签，在界面上点击右键菜单，选择 Mark current values（记录当前值），经过时长测试， 出现较大规模的红色部分（增长部分），且无法GC 性能测试——系统内存占用大 系统内存占用大 检验方式： 进行某些特定的操作，如资源同步。若系统内存数突发性的增长，且之后不回落，说明某些模块在持续性的占用系统资源。 若出现以下现象，可定位系统内存占用问题： 性能测试——系统内存占用大 同上，选择 Mark current values（记录当前值），经过系统模块测试，出现较大规模的红色部分（增长部分），且无法GC（非始终增加） 性能测试——系统内存占用大 堆视图如下：有增长，无法回落，但并非持续性增长 性能测试——系统内存占用大 测试实例： MibNodes节点问题，如上文图中所示。 SNMP模块在缓存MibNode节点信息是，将所有的值长期持有在HashTable中 随着设备发现及同步的进行，该类的数量出现大规模增加，并且在系统退出之前不会进行释放 解决方案： 编写缓存，将这种规模的数据进行了缓存及释放 性能测试——线程数过多 线程数过多 检验方式： 进行某些特定的操作，如资源同步。若系统线程数突发性的增长或持续增长，且之后不回落，说明某些模块在持续性的占用线程。 观察是否有许多线程来自同一个模块、长期处于waiting或block状态 观察如下视图： 性能测试——线程数过多 Thread Views 界面 Thread History标签 Thread Views 界面 Thread Monitor标签 性能测试——线程数过多 测试实例： 资源模型缓存问题 资源模型缓存在使用线程时，采用了自建线程的方式，在某个线程锁上发生了阻塞，导致系统线程数居高不下 解决方案： 检验代码，修正发生阻塞的地方。 建议以后的模块在有类似的需求是，采用线程池的方式 性能测试——工具类实例化多 工具类实例化多： 某些工具类未采用static方式，但系统实例化地方较多，导致实例化出来的类数量很多 该问题会浪费实例化时间以及空间 检验方式： Memory Views界面，Record Object 标签 观察类的实例化数量。如果某个NNM5系统类实例化数量较大，可观察代码，是否为工具类 性能测试——内存泄露 如下图所示：这一系列的实例化数都较多 性能测试——内存泄露 如下图所示：一般的工具类实例化数都为1 性能测试——线程数过多 测试实例： 告警映射生成类问题 如上图所示，在对NNM5系统压力的一期测试中，发现告警映射的类有大量生成问题（量级约为万） 经阅读代码，其中的某些类中没有成员变量，应为工具类型的类 建议阅读相关代码，进行修改 其他的内存监控工具 如果电脑上安装了JDK1.6以上的版本，可以使用Java自带的一个快捷内存监控工具： jvisualvm 其路径为： Java安装目录\ Java\jdk1.6.0_25\bin\ jvisualvm.exe 该软件可进行内存、线程及cpu的相关监控，其使用界面较为简洁。 内存调优方向 健康系统内存表现： 不出现内存泄露 不会出现频繁的GC 是否出现频繁实例化对象 每次GC之后，Heap中的剩余内存量最好占Heap上限值的35%—50%左右，且不出现迅速的增长 GC不会消耗太多的时间，最好在0.5s以下（可通过 –XX:+PrintGCDetails查看GC细节） 线程数量适当 内存调优方向——推荐文档 选择合适的GC算法： –XX:+UseSerialGC Serial –XX:+UseParallelGC Parallel –XX:+UseParallelOldGC Parallel compacting –XX:+UseConcMarkSweepGC Concurrent mark–sweep (CMS) 调整Heap中Young Generation的大小 调整Heap中Old Generation的大小 –XX:NewRatio=n 调整GC在整个程序运行期间的时间比重 –XX:GCTimeRatio=n 其他 内存调优方向——推荐文档 Sun 公司出的官方文档： Memory Management in the Java Hotspot? Virtual Machine 该文档包含了： Sun公司对GC机制的官方解释 4种垃圾回收机制的区别和联系 几乎所有-x系列Jvm指令 内存调优方向——推荐文档 结束 * / 英文目录标题:33-42pt 颜色: R204 G51 B0 字体 : Arial