loadrunner结果分析(内存、GC、was、sql等以及对应工具下载).docVIP

个人总结 待深入研究的知识点： 吞吐率：如何通过吞吐率确定系统瓶颈？如何判断吞吐率的阈值 [Windows]应用服务器CPU占用率持续在90%以上，如何确定瓶颈？ 可能原因及排查方法怀疑系统问题： pslist/process explorer查看java.exe对应进程pid下的所有线程tid，看此时哪个tid占用cpu-user time过多，将tid号转换成16进制； 通过DOS窗口启动%java_home%/bin/jconsole.exe，CPU持续90%以上时，通过Ctrl+Break产生 Thread Dump文件（/bin目录下）；(或参见4（8）中的方法生成threadDump文件) 在（2）产生的Thread Dump文件中查找（1）中的tid（16进制），看相应报错信息 [Windows]CPU负载达到100%时，请求的成功率低 可能原因及排查方法怀疑系统GC： 采样对比请求任务数与GC对比（理想情况下GC周期应该：发生间隔大于10秒 、在1至2秒内完成 /developerworks/cn/websphere/library/techarticles/0602_lurie/0602_lurie.html）； 若关联较大，则可能是JVM设置问题 通过反复试验找到JVM的最优设置 注：相关经验 对于不同的应用程序，最优化堆大小的设置都有可能不同。如果堆设置较大，可能导致 GC 的次数变少，但每次 GC 所花的时间很长，从而导致系统的处理能力抖动很大。此外如果堆设置过大，会占用过多的内存，使内存资源耗尽，从而会频繁的进行 IO 操作来使用虚拟内存。 如果堆设置较小，可能导致 GC 变的频繁，但每次 GC 所花的时间不会太长，每次 GC 对系统的性能影响相对也会小些。但是如果堆设置过小，会使得对象可分配空间变小，从而会频繁的 GC 来释放内存空间，而每次 GC，都会耗用一定的系统资源。因此，要通过试验和监控数据，设法使的我们所设置的堆大小能够使得系统运行最优化。 /developerworks/cn/java/j-lo-optimize-gc/ 《优化 Java 垃圾收集器改进系统性能》 WAS调优： Web容器：CPU数目（一般每个CPU核对应5至10个线程将提供最大吞吐量）、客户对系统的要求（响应时间、吞吐率哪个为首位？）、实际应用（任务小但数目多or任务大但数目少or…） 相关链接： viewspace-600491 WebSphere的池设置——线程池、连接池 /developerworks/cn/java/l-threadPool/ 线程池的介绍及简单实现 数据源连接池： 参考漏斗模型，并根据实际应用（jsp/servlet是否占用1个/多个连接？），结合其他几个参数（web容器等）来设置。 相关链接： /club/viewthread.php?tid=452 WebSphere中流行数据库连接池的配置 JVM：CPU位数、实际内存大小、操作系统、JDK厂家及版本、WAS版本； 相关链接： /club/viewthread.php?tid=8077extra=page%3D1 32bit JVM最大可配置内存是2G还是4G？ GC（Garbage Collection，垃圾回收）策略：（内存回收过程中所有JAVA应用程序都被暂停） IBM JVM GC： WAS 6.1使用JDK5.0，该JDK提供了4种内存回收策略，可以通过设置-Xgcpolicy配置参数来指定使用哪一种策略，否则默认的回收策略很可能影响到应用系统的性能。命令格式如下： -Xgcpolicy :optthruput|optavgpause|gencon|subpool optthruput是默认的回收策略，它不适用并发标记。如果用户没有内存回收时系统暂停时间过程的问题，就可以保持该默认参数； optavgpause，如果内存回收时导致的系统暂停时间过长，建议使用该策略。它可以缩短系统在做内存回收的时候被暂停的时间，尤其是当内存的占用率很高的时候。但是，这种策略会降低系统的吞吐率（大概5%）； gencon是一种将并发标记和传统的垃圾回收机制综合使用的策略，用于将内存回收时的暂停时间最小化； subpool不使用并发标记，但是，使用一种改进的内存分配算法用来获得更好的性能。该策略在CPU16个的时候才能看出提升效果，并且只适用于AIX，Linux PPC，zSeries，z/OS，i5/OS系统。 有实验表明，对于电子商务应用系统，使用后两种比前两种在吞吐率上可以高出30%~60%。 Sun JVM GC： 在SUN J2SE 5.0中，引入了所谓Behavior-based Parallel Collec