文档章节

成为Java GC专家(4)—Apache的MaxClients及其在Tomcat执行FullGC

stefanzhlg
 stefanzhlg
发布于 2014/12/05 18:02
字数 2638
阅读 176
收藏 4

这是“成为Java GC专家系列文章”的第四篇。

在第一篇文章 成为JavaGC专家Part I — 深入浅出Java垃圾回收机制 中我们学习了不同GC算法的执行过程,GC如何工作,新生代及老年代的基本概念,在JDK7中你应该了解的5种GC类型以及他们的性能如何。

在第二篇文章 成为JavaGC专家Part II — 如何监控Java垃圾回收机制 中我们学到了JVM到底是如何执行垃圾回收,我们如何监控GC,以及那些工具可以使得监控过程更高效。

在第三篇文章 成为Java GC专家系列Part III–如何优化Java垃圾回收机制中我们通过实际的例子学到了一些可以优化GC的参数。同时我们讲解了如何减少对象被转移到老年代空间,如何缩短Full GC时间,以及如何设置GC类型及内存空间。

在第四篇文章中,我们将阐述Apache中MaxClients 参数的重要性,以及他如何在GC发生时,显著地影响整个系统的性能。我将提供几个例子以方便你理解MaxClients 导致的问题。同时我还会说明如何根据系统的内存情况,设置最佳的MaxClients参数值。

MaxClients对于系统的影响

NHN (译者注:NHN是作者工作的公司)服务的执行环境中存在一组Throttle valve-type参数(译者注:节流阀参数,用于控制系统负载)。这些参数对于系统来说十分重要。下面我们看一下Apache的 MaxClients 参数在Full GC 发生时是如何影响系统的。

大部分开发人员都知道在由于GC发生而导致的”停止世界现象(STW) “(详细请参见Understanding Java Garbage Collection)。尤其是,NHN的Java开发人员经常会遇到由于GC原因导致的Tomcat报错。由于Java 虚拟机 (JVM)管理着内存,以Java为基础的程序无法摆脱GC导致的STW现象。假如在某一个时间,当你正在操作你开发的应用时,GC开始执行。即使TTS错误没有发生,你的服务也会给客户展现未预期的503错误。

服务执行环境

由于架构本身的特点,相比较而言纵向扩展,Web服务更适合横向扩展(译者注:增加服务器的数量,而不是提高件配置)。因此,总体来讲,物理设备会 根据性能要求被配置成1台Apache+n台Tomcat。但是本文假设我们的环境是1台Apache+一台Tomcat同时安装在一台主机行,如下图所 示。

1:本文假射的服务执行环境

仅供参考,本文描述的参数基于Apache 2.2.21 (prefork MPM),Tomcat 6.0.35,CentOS 4.72 (32-bit),jdk 1.6.0_24。

系统可用内存2GB,垃圾收集器使用ParallelOldGC,AdaptiveSizePolicy采用默认的设置true,堆内存空间600M

STW 和HTTP 503

让我们假设访问Apache的请求为 200 req/s且有10个httpd进程在运行,另外我们暂时不考虑每个请求的响应时间。在这种前提下,我们假设由于full GC导致的暂停时间为1秒。Full GC发生的时候Tomcat会怎样?

第一件进入你脑海的事情应该是Tomcat会因为full GC而停止响应任何请求。在这种情况下,Tomcat暂停相应请求时Apache会发生什么?

当Tomcat暂停时,请求会以200 req/s的速度不断的涌入Apache。一般来说,在Full GC发生之前,请求的响应可以快速地被10个或更多的httpd进程处理掉。但是,因为Tomcat暂停了,httpd进程会被不停地创建以相应新进请求。直到超过httpd.conf 文件中定义 MaxClients 为止。由于默认值为256,Apache不会在乎请求以200 req/s的速度涌入。

这时,新创建的httpd线程将如何呢?

Httpd进程通过mod_jk 模块所管理的空闲的AJP连接,将请求转发给Tomcat。如果没有空闲连接,他会申请创建新的连接。但是,因为Tomcat暂停了,创建新连接的请求会被拒绝。因此这些请求会被存储在backlog队列中,数量的多少取决于server.xml中关于AJP Connector的设置。一旦请求数量超过backlog队列的空间限制。Apache就会返回拒绝连接错误。并且返回HTTP 503 错误给用户。

在这种假设条件下,默认的backlog队列空间是100,而请求到达速度是200 req/s。因此,full GC导致的一秒钟的暂停会使得超过100个请求返回503错误。

这样,当Full GC结束后,backlog队列中存储的内容会被Tomcat接受并在通过工作线程处理,线程的最大数量取决于MaxThreads的值(默认200)。

MaxClients 与backlog

在这种情况下,设定哪个参数可以避免返回给用户503错误呢?

首先,我们应该知道backlog的值要够大,以至于能够容纳所有因为Full GC导致暂停期间涌入的请求。换句话说太应该不小于200。

那么,这么设置之后会不会产生新的问题呢?

让我们假设将backlog设置为200后再重复一下上面的过程。得到的结果比之前更加严重。系统内存使用量一般情况下为50%,但是,在发生 Full GC时快速增加到100%,同时导致交换内存空间快速增加,更为严重的是导致Full GC的暂停时间从1秒变成了4秒甚至更多,系统在此期间完全宕机,不能响应任何请求。

在第一种情况下,只有100或更多的请求返回503错误。但是,当我们把backlog调整到200后,超过500个请求会挂起3秒甚至更多地时间无法得到应答

上面这个例子可以很好的说明当你没有完全理解各个设置之间的内在关系时(例如,对于系统的影响),盲目修改系统会导致什么后果。

那么,为什么会产生这个现象呢?

问题的根源在于 MaxClients 参数的特性。

MaxClients 设置为一个很大的值本身没有问题,但最重要的是在设定MaxClients 参数时,你要确保即使等同于MaxClients 数量的httpd进程被同时创建,内存使用量也不会超过80%

系统的内存交换参数一般被设定为60(默认)。因此,当内存使用量超过80%时,就会进行内存交换。

让我们再来看一下为什么这个特性会导致上面那个严重的问题。当请求以200 req/s的速度涌向Tomcat时,Tomcat由于full GC暂停了。此时backlog被设置为200。Apache大约创建100个httpd进程。在这种情况下,一旦内存使用量超过80%,操作系统会激活 交换内存区域,并且由于系统认为JVM的老年代中的对象在很长一段时间内未被使用,而将他们移动到交换区域。

最终的结果是,GC使用了内存交换空间,暂停时间剧增。因此httpd进程数进一步增加。从而导致上面描述的内存使用量达到100%的情况。

这两个场合的唯一区别就是backlog的值:100 vs.200。为什么只在200的情况下发生?

两者不同的原因在于创建的httpd进程的数量。当backlog设置为100时并且Full GC发生时,会创建100个请求的连接并保存在backlog队列中。其他请求得到拒绝连接错误信息并发挥503错误。因此,总的httpd 进程数量仅仅会略高于100。而当backlog被设置为200时,200个请求会创建连接,因此。总的httpd进程数会多于200。这样超过阀值,从 而导致内存交换的发生。紧接着,不考虑内存使用量而的设定 MaxClients参数,Full GC导致httpd进程数量暴增,引发内存交换,降低系统性能。

MaxClients参数的计算公式

如果系统的内存使2GB,MaxClients 的值在任何情况下都不应该超过内存的80%(1.6GB),以避免由于内存交换导致的性能下降。换句话说。1.6GB的内存应该共享和分配给Apache,Tomcat以及那些默认被安装的代理程序。

让我们假设代理程序被默认安装在系统,并占用了200m内存,对于Tomcat堆内存的-Xmx 被设定为 600m。因此根据top命令的结果,Tomcat会一直占用725m(Perm Gen + Native Heap Area)。最终Apache可以使用700m内存空间。如下所示。

2:测试系统的top截屏

如上所述,我们将内存设为700mMaxClients 应该是多少呢?

这要取决于加载模块的数量,对于NHN Web服务来说。Apache只是个简单的代理转发,每个httpd线程4m内存(根据top命令的结果)足以(参见图2)。因此。700m内存对应的 MaxClients应该是175。

总结

一个健壮的服务配置至少应该能够降低在服务过载时宕机的时间,在合理的范围内成功的应答请求。针对基于Java的Web服务。你必须检查你的服务在Full GC导致的STW时间内能否稳定的响应请求。

为了响应更多的用户请求和应对DDoS攻击,在没有全面考虑系统内存等因素的情况下,贸然地将 MaxClients设置为一个很大的值,那么它将失去作为阀值的功能,而导致系统出现更严重的问题。

本文提到的情况只会持续3-5秒,因此绝大多数传统的监控工具都无法及时的发现。

作者 Dongsoon Choi 高级工程师@Game  Service Technical Support Team, NHN Corporation.

英文原文:cubrid,编译:ImportNew-王晓杰

译文地址: http://www.importnew.com/3151.html

本文转自:http://www.importnew.com/3151.html

© 著作权归作者所有

stefanzhlg

stefanzhlg

粉丝 68
博文 110
码字总数 85559
作品 4
浦东
程序员
私信 提问
加载中

评论(0)

成为Java GC专家(4) — Apache的MaxClients参数详解及其在Tomcat执行F

这是“成为Java GC专家系列文章”的第四篇。 在第一篇文章 成为JavaGC专家Part I — 深入浅出Java垃圾回收机制 中我们学习了不同GC算法的执行过程,GC如何工作,新生代及老年代的基本概念,在...

ihaolin
2014/04/04
150
0
成为Java GC专家系列

成为Java GC专家(1):深入浅出Java垃圾回收机制 成为Java GC专家(2):如何监控Java垃圾回收机制 成为Java GC专家(3):如何优化Java垃圾回收机制 成为Java GC专家(4):Apache的MaxClients参数...

HenrySun
2016/06/21
244
0
成为Java GC专家(4)—Apache的MaxClients参数详解及其在Tomcat执行Ful

这是“成为Java GC专家系列文章”的第四篇。 在第一篇文章 成为JavaGC专家Part I — 深入浅出Java垃圾回收机制 中我们学习了不同GC算法的执行过程,GC如何工作,新生代及老年代的基本概念,在...

Edwyn王
2015/09/22
12
0
成为Java GC专家(5)—Java性能调优原则

这是“成为Java GC专家”系列的第五篇文章。在第一篇深入浅出Java垃圾回收机制中,我们已经学习了不同的GC算法流程、GC的工作原理、新生代(Young Generation)和老年代(Old Generation)的...

stefanzhlg
2014/12/05
1.5K
1
关于GC(中):Java垃圾回收相关基础知识

Java内存模型 (图源: 深入理解JVM-内存模型(jmm)和GC) 区域名 英文名 访问权限 作用 备注 程序计数器 Program Counter Register 线程隔离 标记待取的下一条执行的指令 执行Native方法时为空...

五岳
2019/11/22
0
0

没有更多内容

加载失败,请刷新页面

加载更多

人脸识别签到闸机 测温门禁通道 智能口罩识别

艾力奋口罩人脸识别测温闸机: 在展览会议期间,可对体温异常人员精确筛查告警:通过人脸识别AI算法和黑体对温度数据进行优化和校准后,仅对行人额温进行测量,保证测量精度误差在±0.3℃以内...

osc_wip0vvls
20分钟前
18
0
教你如何实现一个翻页笔插件?

前言 2020 年的第一篇文章,技术源于生活,作为码农,我觉得最得意的事情大概就是解决一个真实可见的问题了。前段时间我在团队做分享的时候,订了一个比较大的培训室,电脑离的远,所以就需要...

好未来技术团队
20分钟前
7
0
concurrentHashmap内容介绍

ConcurrentHashMap 的工作原理及代码实现   ConcurrentHashMap采用了非常精妙的"分段锁"策略,ConcurrentHashMap的主干是个Segment数组。Segment继承了ReentrantLock,所以它就是一种可重入...

osc_5emtajt2
20分钟前
6
0
hashMap在java7的介绍

1.Java:这是一份全面 & 详细的HashMap 1.7源码分析指南(转载) 前言 HashMap 在 Java 和 Android 开发中非常常见 今天,我将带来HashMap 的全部源码分析,希望你们会喜欢。 本文基于版本 ...

osc_5ijle82k
22分钟前
9
0
Modbus协议和应用开发介绍

因业务需要了解Modbus协议的使用,因此对Modbus的协议,以及相应的C#处理应用进行了解,针对协议的几种方式(RTU、ASCII、TCPIP)进行了封装,以及对Modbus的各种功能码的特点进行了详细的了...

osc_8i2fhl7z
23分钟前
9
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部