![]() Figure 1. Single-processor versus multi-processor platforms accessing memory |
| String mem = request.getParameter("memory"); if (mem != null && !mem.equals("")) { int mem_kbytes = Integer.parseInt(mem); byte[] i = new byte[mem_kbytes*1024]; } |
![]() 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、调整应用处理不必要的对象来优化内存争用。