JavaGC(4)Apache的MaxClients参数详解及Tomcat执行FullGC的影响

        在这种情况下&＃xff0c;设定哪个参数可以避免返回给用户503错误呢&＃xff1f;

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

        那么&＃xff0c;这么设置之后会不会产生新的问题呢&＃xff1f;

       让我们假设将backlog设置为200后再重复一下上面的过程。得到的结果比之前更加严重。系统内存使用量一般情况下为50%&＃xff0c;但是&＃xff0c;在发生Full GC时快速增加到100%&＃xff0c;同时导致交换内存空间快速增加&＃xff0c;更为严重的是导致Full GC的暂停时间从1秒变成了4秒甚至更多&＃xff0c;系统在此期间完全宕机&＃xff0c;不能响应任何请求。在第一种情况下&＃xff0c;只有100或更多的请求返回503错误。但是&＃xff0c;当我们把backlog调整到200后&＃xff0c;超过500个请求会挂起3秒甚至更多地时间无法得到应答。

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

那么&＃xff0c;为什么会产生这个现象呢&＃xff1f;问题的根源在于 MaxClients 参数的特性。

        将MaxClients 设置为一个很大的值本身没有问题&＃xff0c;但最重要的是在设定MaxClients 参数时&＃xff0c;你要确保即使等同于MaxClients 数量的httpd进程被同时创建&＃xff0c;内存使用量也不会超过80%。系统的内存交换参数一般被设定为60&＃xff08;默认&＃xff09;。因此&＃xff0c;当内存使用量超过80%时&＃xff0c;就会进行内存交换。

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

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

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

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