Apache的MaxClients参数及其对Tomcat执行Full GC的影响（四）

最新推荐文章于 2024-11-15 18:38:47 发布

weixin_33720452

最新推荐文章于 2024-11-15 18:38:47 发布

阅读量117

点赞数

文章标签： java 运维操作系统

原文链接：http://blog.51cto.com/wangaimin/1909148

版权

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进程数量暴增，引发内存交换，降低系统性能。