性能调整高负载Apache服务器

我想了解一些（对我们而言）负载很重的Web服务器遇到的一些服务器性能问题。环境如下：

• Debian Lenny（所有稳定的软件包以及安全更新补丁）
• 阿帕奇2.2.9
• PHP 5.2.6
• Amazon EC2大型实例

我们看到的行为是，Web通常感觉很敏感，但是开始处理请求时会稍有延迟-有时在我们的高峰使用时间中只有一秒钟的时间，有时是2-3秒。在服务器上的实际负载被报告为非常高-通常10.XX或20.xx如报道top。此外，在这些时间（甚至vi）在服务器上运行其他操作非常慢，因此负载肯定就在那里。奇怪的是，除了最初的延迟之外，Apache仍然保持了快速响应。

我们使用prefork将Apache配置如下：

StartServers          5
MinSpareServers       5
MaxSpareServers      10
MaxClients          150
MaxRequestsPerChild   0

和KeepAlive一样：

KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 5

查看服务器状态页面，即使在这些繁重的时刻，我们也很少遇到客户端限制，通常为80-100个请求以及许多处于keepalive状态的请求提供服务。这告诉我将初始请求的速度排除为“等待处理程序”，但我可能是错的。

Amazon的CloudWatch监控告诉我，即使我们的操作系统报告的负载大于15，我们的实例CPU利用率仍在75-80％之间。

输出示例top：

top - 15:47:06 up 31 days,  1:38,  8 users,  load average: 11.46, 7.10, 6.56
Tasks: 221 total,  28 running, 193 sleeping,   0 stopped,   0 zombie
Cpu(s): 66.9%us, 22.1%sy,  0.0%ni,  2.6%id,  3.1%wa,  0.0%hi,  0.7%si,  4.5%st
Mem:   7871900k total,  7850624k used,    21276k free,    68728k buffers
Swap:        0k total,        0k used,        0k free,  3750664k cached

大多数过程如下所示：

24720 www-data  15   0  202m  26m 4412 S    9  0.3   0:02.97 apache2                                                                       
24530 www-data  15   0  212m  35m 4544 S    7  0.5   0:03.05 apache2                                                                       
24846 www-data  15   0  209m  33m 4420 S    7  0.4   0:01.03 apache2                                                                       
24083 www-data  15   0  211m  35m 4484 S    7  0.5   0:07.14 apache2                                                                       
24615 www-data  15   0  212m  35m 4404 S    7  0.5   0:02.89 apache2            

vmstat与上述同时输出的示例：

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 8  0      0 215084  68908 3774864    0    0   154   228    5    7 32 12 42  9
 6 21      0 198948  68936 3775740    0    0   676  2363 4022 1047 56 16  9 15
23  0      0 169460  68936 3776356    0    0   432  1372 3762  835 76 21  0  0
23  1      0 140412  68936 3776648    0    0   280     0 3157  827 70 25  0  0
20  1      0 115892  68936 3776792    0    0   188     8 2802  532 68 24  0  0
 6  1      0 133368  68936 3777780    0    0   752    71 3501  878 67 29  0  1
 0  1      0 146656  68944 3778064    0    0   308  2052 3312  850 38 17 19 24
 2  0      0 202104  68952 3778140    0    0    28    90 2617  700 44 13 33  5
 9  0      0 188960  68956 3778200    0    0     8     0 2226  475 59 17  6  2
 3  0      0 166364  68956 3778252    0    0     0    21 2288  386 65 19  1  0

最后，从Apache的输出server-status：

Server uptime: 31 days 2 hours 18 minutes 31 seconds
Total accesses: 60102946 - Total Traffic: 974.5 GB
CPU Usage: u209.62 s75.19 cu0 cs0 - .0106% CPU load
22.4 requests/sec - 380.3 kB/second - 17.0 kB/request
107 requests currently being processed, 6 idle workers

C.KKKW..KWWKKWKW.KKKCKK..KKK.KKKK.KK._WK.K.K.KKKKK.K.R.KK..C.C.K
K.C.K..WK_K..KKW_CK.WK..W.KKKWKCKCKW.W_KKKKK.KKWKKKW._KKK.CKK...
KK_KWKKKWKCKCWKK.KKKCK..........................................
................................................................

根据我有限的经验，我得出以下结论/问题：

• 我们可能允许太多KeepAlive请求

• 我确实在vmstat中看到了一些时间来等待IO，尽管不一致和不是很多（我想？），所以我不确定这是否是一个大问题，我对vmstat的经验不足

• 同样在vmstat中，在一些迭代中，我看到一些等待服务的进程，这就是我将Web服务器上的初始页面加载延迟归因于（可能是错误地）的原因。

• 我们混合使用静态内容（75％或更高）和脚本内容，脚本内容通常占用大量处理器资源，因此在两者之间找到合适的平衡非常重要；从长远来看，我们希望将静态变量移至其他位置以优化两台服务器，但我们的软件目前尚无法满足要求

如果有人有任何想法，我很乐意提供其他信息，另外一点是，这是一个高可用性的生产安装，因此我很谨慎地进行调整，这就是为什么我没有像KeepAlive自己这样玩的原因然而。

首先，我承认我不太想在云中运行东西-但根据我在其他地方的经验，我会说此网络服务器配置反映的流量相当低。运行队列太大说明没有足够的CPU来处理它。运行队列中还有什么？

我们可能允许太多的KeepAlive请求

否-keeplive仍然可以提高性能，现代浏览器非常聪明，可以知道何时进行管道传输和何时并行运行请求，尽管5秒钟的超时时间仍然很高，而且您要等待很多服务器-除非您如果遇到巨大的延迟问题，建议将其降低到2-3。这应该稍微缩短运行队列。

如果尚未在网络服务器上安装mod_deflate-那么我建议您这样做-并将ob_gzhandler（）添加到您的PHP脚本中。您可以将其作为自动添加：

if(!ob_start("ob_gzhandler")) ob_start();

（是的，压缩使用了更多的CPU-但是您应该通过使服务器更快地退出运行队列/处理更少的TCP数据包来节省CPU的总和，而且，您的站点也更快）。

我建议为MaxRequestsPerChild设置一个上限-大约为500。这会允许进程发生一些周转，以防万一内存泄漏。您的httpd进程看起来非常庞大-确保已删除不需要的所有apache模块，并确保使用良好的缓存信息提供静态内容。

如果仍然遇到问题，则问题可能出在PHP代码中（如果您切换到使用fastCGI，这应该很明显，而不会造成任何重大性能损失）。

更新

如果静态内容在页面之间变化不大，那么可能还值得尝试：

if (count($_COOKIE)) {
    header('Connection: close');
}

在PHP脚本上。

您应该考虑安装异步反向代理，因为处于W状态的进程数量也很高。您的Apache进程似乎花费大量时间通过网络将内容发送给速度较慢的客户端，从而阻止了该过程。Nginx或lighttpd作为Apache服务器的前端可以大大减少W状态下的进程数量。是的，您应该限制一些保持活动请求。可能值得尝试关闭keepalive。

顺便说一句，107个Apache进程对于22 rps来说太高了，我仅使用5个Apache进程就能够提供100-120 rps。下一步可能是分析您的应用程序。

vmstat中有两行显示CPU等待时间相当长，在这些行周围，您进行了大量的写入（io-bo）和上下文切换。我将研究什么构成了障碍，以及如何消除这种等待。我认为最大的改进可能是改善磁盘IO。检查系统日志-将其设置为写入异步。确保控制器的写缓存正常工作（检查它-电池可能已损坏）。

Keepalive不会引起性能问题，如果您没有在前面运行缓存，它可以节省连接设置的时间。您可能会碰到MaxSpareServers，这样一来您就不必等待所有的分叉了。

您应该考虑先关闭Keepalive ...

处理了107个请求后，我会保持MaxSpareServers高于设置的值...

长期使用nginx作为静态内容的反向代理的IMHO应该被考虑在内

第一个建议：禁用keepalives。仅当我能确定性能提高但在启用Keepalive的情况下通常每秒请求减少的情况下，才需要它。

第二个建议：设置一个MaxRequestsPerChild。我在这里回显symcbean，它将在发生内存泄漏的情况下帮助进程过渡。500是一个很好的起点。

第三个建议：增加MaxClients。一个基本的计算方法是（物理内存-非httpd进程使用的内存）/每个httpd进程的大小。根据httpd的编译方式，此数字最大为255。我将250用于我的公共服务器，以处理google / yahoo / MS对系统进行爬网的情况。

第四条建议：增加MaxSpareServers：类似于4-5倍的MinSpareServers。

除非这些建议失败，否则我将考虑使用反向代理或数据库的内存缓存进行负载平衡。