多处理器平台上J2EE应用的内存争用

下载本文示例代码
　　随着在企业级环境对高可扩展性J2EE应用的需求，需要在多处理器平台上执行线程的并行处理。在JVM堆中对线程处理所需要的内存和并发处理已经成为这些J2EE应用在部署时的性能和可扩展性的瓶颈。这篇文章探讨了J2EE应用在多处理器平台上访问JVM堆中的内存的线程同步问题。　　　　J2EE应用的内存需求　　　　当前布署在企业级环境中的J2EE应用都需要在一秒中能够处理成千上万的用户请求。这种来自大量并发用户的数据请求就产生了更大堆空间的需求，也就需要更多的内存。有了更多的内存就可以提供更大的J2EE应用堆空间，而多处理器可以处理更多的并发线程，因而现在线程访问内存的方式和访问所花费的时间就成了瓶颈所在。　　　　多处理器平台　　　　处理器数目的增加可以提高可扩展性，但同时需要处理更多的线程。线程在处理数据、创建Java对象及其他Java操作时都有需要耗用内存。由于多个线程在多个处理器中运行，就需要保证在系统中数据的一致性和完整性。在处理器中的线程同时读写内存，这就需要同步这些线程来防止读写错误的数据。在图1中，显示单处理器与多处理器在访问内存时的异同。在单处理器平台中，在任何给定的时间只有一个线程被执行，因此不需要同步。然而在多处理器平台，同一时间可能会有多个线程被执行，这就需要同步访问内存来保证数据的正确性，而这就会导致争用和瓶颈?　　 　　　Figure 1. Single-processor versus multi-processor platforms accessing memory　　“线程本地堆”尝试通过为每一个线程在JVM堆中预分配一小块内存来解决这个问题。然而这种方式下内存空间对高内存需求的J2EE应用来说是不够的。　　　　实验和观察　　　　我们会在一个8CPU平台上为J2EE应用做一项实验，下面是实验的代码：　　 　　String mem = request.getParameter("memory");　　if (mem != null && !mem.equals("")) {　　　int mem_kbytes = Integer.parseInt(mem);　　　byte[] i = new byte[mem_kbytes*1024];　　}　　在每一次测试中，这些J2EE线程会请求创建一个特定内存大小的对象。在一个多用户负载测试中，我们观察到下列的数据：响应时间、吞吐量和资源利用率。　　　　我们将JVM堆大小设置为一个较大的值这样就可以减少垃圾回收的次数。我们注意到即使负载增加，“垃圾回收暂停时间”与“运行总时间”的比率始终在1：35左右，因此我们认为他在这项实验中的影响较小。结果如下图2。 　　　Figure 2. Results of shared memory access on multi-processor platform 　　这个实验的环境如下：　　1、应用服务器：WebLogic7　　2、JVM：Sun JVM 1.3　　3、操作系统：Windows 2000高级服务器版　　4、硬件：Intel Dell PowerEdge 8450 (8Intel Xeon 800MHz 处理器, 4GB RAM)　　5、网络：100Mbps Cisco网络　　6、负载测试工具：WebLoad　　　　我们观察到在增加特定内存大小的对象的负载时，吞吐量增加的比率与CPU利率的增加比较并不相同。当然，响应时间的增加也不是线性的。这些实验清晰地显示了这些J2EE线程的高内存需求导致系统内的争用并且成为J2EE可扩展性的瓶颈。我们还观察到这些线程访问内存和创建对象所花费的时间随着处理利用率的增加而增加。这可以从负载的增加导致服务请求的增加中看出来，如图3中特定内存大小的Java对象的创建图表。 　　　Figure 3. Increase in service demand versus load for Java objects of different memory sizes 　　扩展　　　　内存争用是系统架构所固有的，减轻这个问题的最佳方法是在布署配置中增加更多的系统来保证负载均衡，如下图所示。在一个系统中增加更多的处理器并只会因为允许执行更多的并发线程而增加内存争用，这对增加吞吐量和响应时间并没有什么帮助。 　　　Figure 4. Scale out of application server machine 　　基础结构大小　　　　处理器中线程访问内存的时间增加了处理器的时间，因此处理器使用率也增加了。在多处理器平台中访问内存的线程越多，处理器的效率就越低。为了增加处理量而增加更多处理器在这种情况下并没有什么好处而且会导致J2EE应用低效的容量安排。为预测性能和基础架构的定量或模拟模型在这儿可以派上用处。　　　　应用的内存调优　　　　减少这种问题的一个最重要的步骤就是调优J2EE应用中的不必要的和未回收的对象。任何的内存调试器都可以帮你定位内存瓶颈并且做一些优化，其中一个是JProbe。内存调试器会给出应用的内存分布图，指示对象创建的位置和内存的使用量。他们也指出那些未回收的对象，这些对象会导致应用中的内存泄漏。对象重用也是内存优化的一个考虑因素，而这可以通过缓存框架如Apache JCS来帮忙。这些缓存框架有助于在特定的时间周期中为应用存储特定的对象在缓存中并且可以被重用。　　　　小结　　　　在多处理器平台中保持数据的正确性需要在线程的处理过程中使用同步，这正是导致J2EE应用高内存需求的原因。内存争用的可能解决方案包括：　　　　1、通过为布署配置增加更多的系统。　　　　2、调整应用处理不必要的对象来优化内存争用。 　　随着在企业级环境对高可扩展性J2EE应用的需求，需要在多处理器平台上执行线程的并行处理。在JVM堆中对线程处理所需要的内存和并发处理已经成为这些J2EE应用在部署时的性能和可扩展性的瓶颈。这篇文章探讨了J2EE应用在多处理器平台上访问JVM堆中的内存的线程同步问题。　　　　J2EE应用的内存需求　　　　当前布署在企业级环境中的J2EE应用都需要在一秒中能够处理成千上万的用户请求。这种来自大量并发用户的数据请求就产生了更大堆空间的需求，也就需要更多的内存。有了更多的内存就可以提供更大的J2EE应用堆空间，而多处理器可以处理更多的并发线程，因而现在线程访问内存的方式和访问所花费的时间就成了瓶颈所在。　　　　多处理器平台　　　　处理器数目的增加可以提高可扩展性，但同时需要处理更多的线程。线程在处理数据、创建Java对象及其他Java操作时都有需要耗用内存。由于多个线程在多个处理器中运行，就需要保证在系统中数据的一致性和完整性。在处理器中的线程同时读写内存，这就需要同步这些线程来防止读写错误的数据。在图1中，显示单处理器与多处理器在访问内存时的异同。在单处理器平台中，在任何给定的时间只有一个线程被执行，因此不需要同步。然而在多处理器平台，同一时间可能会有多个线程被执行，这就需要同步访问内存来保证数据的正确性，而这就会导致争用和瓶颈?　　 　　　Figure 1. Single-processor versus multi-processor platforms accessing memory　　“线程本地堆”尝试通过为每一个线程在JVM堆中预分配一小块内存来解决这个问题。然而这种方式下内存空间对高内存需求的J2EE应用来说是不够的。　　　　实验和观察　　　　我们会在一个8CPU平台上为J2EE应用做一项实验，下面是实验的代码：　　 　　String mem = request.getParameter("memory");　　if (mem != null && !mem.equals("")) {　　　int mem_kbytes = Integer.parseInt(mem);　　　byte[] i = new byte[mem_kbytes*1024];　　}　　在每一次测试中，这些J2EE线程会请求创建一个特定内存大小的对象。在一个多用户负载测试中，我们观察到下列的数据：响应时间、吞吐量和资源利用率。　　　　我们将JVM堆大小设置为一个较大的值这样就可以减少垃圾回收的次数。我们注意到即使负载增加，“垃圾回收暂停时间”与“运行总时间”的比率始终在1：35左右，因此我们认为他在这项实验中的影响较小。结果如下图2。 　　　Figure 2. Results of shared memory access on multi-processor platform 　　这个实验的环境如下：　　1、应用服务器：WebLogic7　　2、JVM：Sun JVM 1.3　　3、操作系统：Windows 2000高级服务器版　　4、硬件：Intel Dell PowerEdge 8450 (8Intel Xeon 800MHz 处理器, 4GB RAM)　　5、网络：100Mbps Cisco网络　　6、负载测试工具：WebLoad　　　　我们观察到在增加特定内存大小的对象的负载时，吞吐量增加的比率与CPU利率的增加比较并不相同。当然，响应时间的增加也不是线性的。这些实验清晰地显示了这些J2EE线程的高内存需求导致系统内的争用并且成为J2EE可扩展性的瓶颈。我们还观察到这些线程访问内存和创建对象所花费的时间随着处理利用率的增加而增加。这可以从负载的增加导致服务请求的增加中看出来，如图3中特定内存大小的Java对象的创建图表。 　　　Figure 3. Increase in service demand versus load for Java objects of different memory sizes 　　扩展　　　　内存争用是系统架构所固有的，减轻这个问题的最佳方法是在布署配置中增加更多的系统来保证负载均衡，如下图所示。在一个系统中增加更多的处理器并只会因为允许执行更多的并发线程而增加内存争用，这对增加吞吐量和响应时间并没有什么帮助。 　　　Figure 4. Scale out of application server machine 　　基础结构大小　　　　处理器中线程访问内存的时间增加了处理器的时间，因此处理器使用率也增加了。在多处理器平台中访问内存的线程越多，处理器的效率就越低。为了增加处理量而增加更多处理器在这种情况下并没有什么好处而且会导致J2EE应用低效的容量安排。为预测性能和基础架构的定量或模拟模型在这儿可以派上用处。　　　　应用的内存调优　　　　减少这种问题的一个最重要的步骤就是调优J2EE应用中的不必要的和未回收的对象。任何的内存调试器都可以帮你定位内存瓶颈并且做一些优化，其中一个是JProbe。内存调试器会给出应用的内存分布图，指示对象创建的位置和内存的使用量。他们也指出那些未回收的对象，这些对象会导致应用中的内存泄漏。对象重用也是内存优化的一个考虑因素，而这可以通过缓存框架如Apache JCS来帮忙。这些缓存框架有助于在特定的时间周期中为应用存储特定的对象在缓存中并且可以被重用。　　　　小结　　　　在多处理器平台中保持数据的正确性需要在线程的处理过程中使用同步，这正是导致J2EE应用高内存需求的原因。内存争用的可能解决方案包括：　　　　1、通过为布署配置增加更多的系统。　　　　2、调整应用处理不必要的对象来优化内存争用。 下载本文示例代码


多处理器平台上J2EE应用的内存争用多处理器平台上J2EE应用的内存争用多处理器平台上J2EE应用的内存争用多处理器平台上J2EE应用的内存争用多处理器平台上J2EE应用的内存争用多处理器平台上J2EE应用的内存争用多处理器平台上J2EE应用的内存争用多处理器平台上J2EE应用的内存争用多处理器平台上J2EE应用的内存争用多处理器平台上J2EE应用的内存争用多处理器平台上J2EE应用的内存争用多处理器平台上J2EE应用的内存争用多处理器平台上J2EE应用的内存争用多处理器平台上J2EE应用的内存争用多处理器平台上J2EE应用的内存争用