linux apache 并发,linux – Apache性能在大约256个并发请求之后急剧下降

我正在运行一个流量相对较低的网站,在网站更新后每周一次访问量大幅增加.在这次飙升期间,与本周剩余时间相比,现场表现极差.服务器上的实际负载仍然非常低,可靠地在10％CPU和30％RAM下(硬件应该完全过度杀死我们实际做的事情),但由于某种原因,Apache似乎无法应对数量请求.我们在RHEL 5.7,内核2.6.18-274.7.1.el5,x86_64上运行apache 2.2.3.

尝试在ab的非工作时间重现这种行为,当超过大约256个用户时,我发现性能大幅下降.使用尽可能小的用例运行测试我可以提出(检索静态文本文件,总共223个字节)性能始终正常,245个并发请求：

Connection Times (ms)

min mean[+/-sd] median max

Connect: 15 25 5.8 24 37

Processing: 15 65 22.9 76 96

Waiting: 15 64 23.0 76 96

Total: 30 90 27.4 100 125

Percentage of the requests served within a certain time (ms)

50% 100

66% 108

75% 111

80% 113

90% 118

95% 120

98% 122

99% 123

100% 125 (longest request)

但是,当我同时提出265个同时请求时,其中一部分请求开始花费大量时间来完成：

Connection Times (ms)

min mean[+/-sd] median max

Connect: 13 195 692.6 26 3028

Processing: 15 65 21.3 72 100

Waiting: 15 65 21.3 71 99

Total: 32 260 681.7 101 3058

Percentage of the requests served within a certain time (ms)

50% 101

66% 108

75% 112

80% 116

90% 121

95% 3028

98% 3040

99% 3044

100% 3058 (longest request)

这些结果在多次运行中非常一致.由于还有其他流量进入那个盒子,我不确定硬切断的确切位置,如果有的话,但似乎可疑接近256.

当然,我认为这是由prefork中的线程限制引起的,所以我继续调整配置以使可用线程数增加一倍,并防止线程池不必要地增长和收缩：

StartServers 512

MinSpareServers 512

MaxSpareServers 512

ServerLimit 512

MaxClients 512

MaxRequestsPerChild 5000

mod_status确认我现在运行512个可用线程

8 requests currently being processed, 504 idle workers

但是,尝试265个同时请求仍然会产生与之前几乎相同的结果

Connection Times (ms)

min mean[+/-sd] median max

Connect: 25 211 714.7 31 3034

Processing: 17 94 28.6 103 138

Waiting: 17 93 28.5 103 138

Total: 57 306 700.8 138 3071

Percentage of the requests served within a certain time (ms)

50% 138

66% 145

75% 150

80% 161

90% 167

95% 3066

98% 3068

99% 3068

100% 3071 (longest request)

在搜索了文档(和Stack Exchange)之后,我无法进行进一步的配置设置以尝试解决这个瓶颈问题.有什么东西我不见了吗？我应该开始寻找apache之外的答案吗？有没有人见过这种行为？任何帮助将不胜感激.

编辑：

根据Ladadadada的建议,我对阿帕奇进行了调查.我尝试了-tt和-T几次,找不到任何与众不同的东西.然后我尝试对所有当前运行的apache进程运行strace -c,并得到了：

% time seconds usecs/call calls errors syscall

------ ----------- ----------- --------- --------- ----------------

22.09 0.317836 5 62128 4833 open

19.91 0.286388 4 65374 1896 lstat

13.06 0.187854 0 407433 pread

10.70 0.153862 6 27076 semop

7.88 0.113343 3 38598 poll

6.86 0.098694 1 100954 14380 read

(… abdridged)

如果我正确地阅读(并且忍受我,因为我不经常使用strace),系统调用都不能解释这些请求所花费的时间.在请求甚至到达工作线程之前,它几乎看起来像瓶颈.

编辑2：

有几个人建议,我在网络服务器上再次运行测试(以前测试是从中立的互联网位置运行).结果令人惊讶：

Connection Times (ms)

min mean[+/-sd] median max

Connect: 0 11 6.6 12 21

Processing: 5 247 971.0 10 4204

Waiting: 3 245 971.3 7 4204

Total: 16 259 973.3 21 4225

Percentage of the requests served within a certain time (ms)

50% 21

66% 23

75% 24

80% 24

90% 26

95% 4225

98% 4225

99% 4225

100% 4225 (longest request)

底线时间类似于基于互联网的测试,但在本地运行时似乎总是有点差.更有趣的是,个人资料发生了巨大变化.然而,在大量长时间运行的请求时间用于“连接”之前,瓶颈似乎处于处理或等待状态.我不得不怀疑这可能是一个单独的问题,以前被网络限制掩盖了.

再次从与Apache主机相同的本地网络上的另一台机器运行测试,我看到了更合理的结果：

Connection Times (ms)

min mean[+/-sd] median max

Connect: 1 2 0.8 2 4

Processing: 13 118 99.8 205 222

Waiting: 13 118 99.7 204 222

Total: 15 121 99.7 207 225

Percentage of the requests served within a certain time (ms)

50% 207

66% 219

75% 220

80% 221

90% 222

95% 224

98% 224

99% 225

100% 225 (longest request)

这两个测试共同提出了许多问题,但与此不同的是,现在有一个令人信服的案例可以解决在一定负载下发生的某种严重的网络瓶颈问题.我认为接下来的步骤将分别调查网络层.