“ AH00485:记分板已满,而不是在MaxRequestWorkers上”的含义是什么?


25

我的环境

  • CentOS 6.4 X86_64
  • 阿帕奇2.4.4
  • PHP 5.4.16(FPM)
  • 2个Intel Xeon E5-2620 @ 2.00GHz(8核,每个处理器16个线程)
  • 48GB RAM注册的内存。
  • 3硬盘15RPM 145GB在RAID0中(通过BIO

有趣的变量

    <IfModule mpm_event_module>
        StartServers             2
        ThreadLimit             196
        MinSpareThreads         96
        MaxSpareThreads        192
        ThreadsPerChild         96
        MaxRequestWorkers      192
        MaxConnectionsPerChild   96
    </IfModule>

Apache服务器状态

服务器版本:Apache / 2.2.4(Unix)OpenSSL / 1.0.1e mod_fastcgi / mod-fastcgi-SNAP-0910052141
服务器内置:2013年5月24日16:48:07


当前时间:2013年6月17日星期一09:48:11 COT
重新启动时间:2013年6月17日星期一08:35:14 COT
父服务器配置。生成:1个
父服务器MPM生成:0
服务器正常运行时间:1小时12分钟57秒
服务器负载:0.05 0.10 0.09
总访问量
:14144- 总流量:349.7 MB CPU使用量:u.28 s.25 cu0 cs0-.0121%CPU负载
3.23请求/秒-81.8 kB /秒-25.3 kB /请求
1当前正在处理的请求,191个空闲工作程序

  PID | Connections       | Threads     | Async connections
      | total | accepting | busy | idle | keep-alive | closing
  ==============================================================
18997 | 3     | yes       | 1    | 95   | 0          | 3
18485 | 0     | yes       | 0    | 96   | 0          | 0
  ==============================================================
Sum   | 3     |           | 1    | 191  | 0          | 3

错误记录

错误消息是

[2013年6月17日星期一09:32:45.680842] [mpm_event:error] [pid 8574:tid 140185091581760] AH00485:记分板已满,而不是在MaxRequestWorkers

这每隔几秒钟就会出现一次。我不明白 我该如何解决?

Answers:


18

我们在Apache 2.4.6上遇到了同样的问题。监视服务器并调整设置几个小时后,我们发现Apache可能有错误。似乎发生的情况是服务器进程偶尔进入G状态(正常完成)并重新启动以接受新请求,这是正常的。这是不正常的,由于某种原因,这可能需要几分钟才能重新启动。如果只有少数几个服务器进程正在运行,并且它们全部同时进入G状态,则记分板将满,您将无法再处理任何请求。

我们所做的是增加了服务器的数量,因此它们全部同时进入G状态的可能性较小。还要确保MaxRequestWorkers为每个服务器进程分配至少25个线程(),因为这似乎是默认值(即5 Serversx 25 ThreadsPerChild= 125 MaxRequestWorkers)。您可以根据ThreadsPerChild需要进行更改,我们默认将其保留。如果没有分配足够的线程,则其他服务器将无法启动。我们保留MinSpareThreads默认值25和默认值MaxSpareThreads75。如果您确实修改了这些设置,则for的值MaxSpareThreads必须大于或等于MinSpareThreadsThreadsPerChild。还MaxRequestWorkers必须等于或小于ServerLimit

这是对我们有用的,但它可能不是您的最佳配置。

StartServers 3
MinSpareServers 5
MaxSpareServers 10
ServerLimit 250
MaxRequestWorkers 250
MaxConnectionsPerChild 1000
KeepAlive Off

编辑:这是httpd的mpm_event模块中的一个已确认错误,该错误可能无法通过配置修复
链接的bugtracker条目具有一个假定的修补程序,以及有关在正式发布新版本的事件模块之前如何解决此问题的更多讨论。


您的MaxConnectionsPerChild设置太低,无法用于生产。此外,将其设置为0以外的任何值仅意味着在Windows上可以完成,因为它会在内部泄漏内存。
rustyx

Apache error_log还提供了提示:MaxRequestWorkers of 40 is not an integer multiple of ThreadsPerChild of 25, decreasing to nearest multiple 25
dhaupin '16

1
MaxSpareServers / MinSpareServers不适用于mpm_event。我不确定您的意思,因为数字太低而无法达到MaxSpareThreads / MinSpareThreads。
哈米什·莫法特

在Apache2日志轮转时在Debian上也遇到了麻烦。请参阅support.plesk.com/hc/en-us/articles/...
伊夫·马丁

此答案中提到的补丁已合并到2.4.25中。我在这里是因为我有问题,尽管我正在使用2.4.25。显然,它出现在由logrotate触发的重新加载中,并且进程继续写入error.log.1error.log只提到重装。
杰罗姆'18

3

看到同样的问题。

Apache 2.4.7-1ubuntu4.4 on Ubuntu 14.04
Server Version: Apache/2.4.7 (Ubuntu)
Server MPM: event
Server Built: Mar 10 2015 13:05:59 

特别是,我们可以通过重新加载apache来导致此行为。

然后,我们看到了一些不会停止的旧过程:

root     28192  0.0  0.8 103772  8648 ?        Ss   Mar16   0:03 /usr/sbin/apache2 -k start
www-data  2530  0.3  2.1 865188 21516 ?        Sl   06:26   0:54  \_ /usr/sbin/apache2 -k start
www-data  2531  0.2  2.1 865436 21892 ?        Sl   06:26   0:51  \_ /usr/sbin/apache2 -k start
www-data  3299  0.3  2.0 864140 20628 ?        Sl   06:46   0:51  \_ /usr/sbin/apache2 -k start
www-data  7305  0.3  2.1 865100 21504 ?        Sl   08:36   0:37  \_ /usr/sbin/apache2 -k start
www-data 11952  0.2  1.8 863004 19268 ?        Sl   10:46   0:06  \_ /usr/sbin/apache2 -k start
www-data 13284  0.0  0.6 103772  6692 ?        S    11:18   0:00  \_ /usr/sbin/apache2 -k start
www-data 13553  2.1  2.0 866156 21248 ?        Sl   11:23   0:01  \_ /usr/sbin/apache2 -k start

注意“较旧”和“较新”的PID和开始时间。^^

PID Connections     Threads Async connections
total   accepting   busy    idle    writing keep-alive  closing
7305    14  no  0   0   0   0   0
2530    13  no  0   0   0   0   0
3299    7   no  0   0   0   0   0
13553   65  no  17  8   0   25  25
2531    15  no  0   0   0   0   0
11952   10  no  0   0   0   0   0
Sum 124     17  8   0   25  25

GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG
GGGGGGGGGGGW_WWWW__W_W_W_WWWWWWW__WWGGGGGGGGGGGGGGGGGGGGGGGGGGGG
GGGGGGGGGGGGGGGGGGGGGG

0

当我们的一个副本数据库脱机并开始超时时,我们开始看到这种情况。显然,这将Apache的大量线程捆绑在一起,直到事情变得相当糟糕为止,我们才开始收到此消息。

可能不是正常情况,但我将此问题提交给佳能,希望它可以对看到此错误的其他人有所帮助。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.