优化 Java 垃圾收集器改进系统性能.pdfVIP

优化 Java 垃圾收集器改进系统 性能 级别： 高级 李 晓华 (xiaohual@), IBM CDL ODSC 部门工程师 2006 年 11 月 30 日 在系统的性能测试过程中，当系统的处理能力有某种变化趋势时，除了关于等待队列、执行线程，EJB 池 以及数据库连接池和 Statement Cache 方面的调 外，还要考虑到 Java 垃圾收集器（Garbage Collection，本文简称 GC）对系统性能的影响。本文介绍了如何分析系统的处理能力和 GC 之间的关 系，以及如何通过改进 JVM 的配置来优化 GC，以提高系统的性能。 项目背景 某个大型项目的 CPU100% 的压力性能测试， 用以检查在系统运行环境不正常的情况下，系统可以运 行到何种程度。测试过程是：请求测试的模拟器向系统不断发出大量请求, 系统接受由模拟器发出的请求， 然后将请求 于一个任务池中，如果当前有空闲的线程，则该线程会从任务池中取出一个任务进行处理， 如果没有空闲的线程，则该任务一直会待在任务池中，直到有空闲的线程来处理它。因此，任务池的队 列的长度从某种意义上可以代表整个系统的处理能力，任务池队列的长度用 Q 值来表示，如果 Q 值超 出了一定限额，将会有流量控制的线程将超出限额的待处理任务丢弃，以保证系统的稳定性。 整个测试要求得到系统所在服务器的负载达到将近 100% 时，系统的吞吐量，相应时间以及在超负荷 下业务请求成功率。 问题现象描述 在测试过程中，任务池中累积的任务数起伏 大，正常时累积的任务数很小，但是每隔一段时间会累积 大量的任务。由于累积的任务数超出任务池流量控制所定义的限额，所以每隔一段时间，大量的待处理 任务被清除。因此测试结束后得到的在超负荷下业务请求成功率也不是 理想。 应用服务器的物理部署 一台AIX 服务器（4CPU，4GMemory）来部署本Web 应用程序；Web 应用程序部署在中间件应用服 务器上；部署了一个节点 （Node），只配 一个应用服务器实例 （Instance），没有做 Cluster 部署。 分析 检测 WebSphere Application Server 上的 Web Container，EJB Container ， ORB Service， 数据库连接池等设 均合理，然后怀疑问题的现象是不是与系统 GC 有关。当前 Java Virtual Machine 的配 为：Initial Heap Size：256 ， Maximum Heap Size：3072。 为了验证任务池中累积的任务数的大幅度变化和系统 GC 是否存在一定的关系，通过对任务池的累积任 务数和系统 GC 进行采样，将采样后的数据进行分析，用以得出二者的关系。采样时遵循 Nyquist 采 样定例：采样频率要大于被采集对象的频率的 2 倍。 否则，采样点 可能每次位于被采集对象的波形 的某个点上，从而不能正确反映被采集对象的变化规律。 采样 通过观察，发现任务池的任务数目(以下用 Q 值代替)的变化周期大概是 5 到 6 秒，因此根据 Nyquist 采样定例，采样的时间间隔不能超过 2-3 秒，所以按照每秒来采样。测试时间是 3 分钟，采样 180 次， 系统的当前负载率是 99%。采样图如下所示： PDF 文件使用 pdfFactory 试用版本创建 图一 任务池 Q 值的采样图 由于系流量控制要求的限额是 450 个任务，也就是任务池中最多能累积 450 个任务，当任务池中