如何调试apache超时?


14

我使用,在Apache 2.2服务器(Ubuntu服务器10.04、8x2GHz,12Gb RAM)上运行PHP Web应用程序prefork。Apache每天大约收到10万至20万个请求,其中约100-200个达到了超时限制(因此大约每千个中有一个),几乎所有其他请求都在超时以下得到很好的服务。

我该怎么做才能找出原因呢?或者让所有请求中的一小部分超时是正常的吗?

到目前为止,这是我所做的:

请求响应时间

可以看出,在超时限制和更合理的请求之间的请求很少。目前,超时限制设置为50秒,之前设置为300秒,但仍然是相同的情况,但存在一些超时,然后与其他请求之间的差距很大。

超时的所有请求都是AJAX请求,但是绝大多数都是,所以也许更多是巧合。Apache的返回码为200,但显然已达到超时限制。它们来自各种不同的IP。

我查看了超时的请求,如果我执行相同的请求,它们在不到一秒钟的时间内完成,它们就没有什么特别的。

我试图查看不同的资源,看看是否可以找到原因,但没有运气。总是有足够的可用内存(最少约3GB可用空间),有时负载高达1.4,CPU利用率达到40%,但是许多超时发生在负载和CPU利用率较低时。白天磁盘写/读几乎是恒定的。MySQL慢查询日志中没有条目(设置为记录1秒以上的任何内容),没有请求使用的数据库写/读次数很多。

请求响应时间与系统负载/ CPU

蓝色是CPU利用率,峰值是40%,栗色是负载,峰值是1.4。因此,即使CPU使用率/负载较低,我们也可以看到超时(十秒的峰值与CPU使用率非常吻合,但这是另一个问题,我更希望找出可能导致这些情况的原因)。

Apache错误日志中没有错误,我还没有看到它达到200多个活动的Apache进程。

服务器设置:

Timeout 50 
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 2

<IfModule mpm_prefork_module>
    ServerLimit     350
    StartServers        20
    MinSpareServers     75
    MaxSpareServers     150
    MaxClients          320
    MaxRequestsPerChild 5000
</IfModule>

更新:

我已更新到Ubuntu 12.04.1,以防万一。我用设置添加了mod_reqtimeout:

RequestReadTimeout header=20-40,minrate=500
RequestReadTimeout body=10,minrate=500

现在几乎所有超时发生在10秒,一两次发生在20秒。我的意思是,大多数情况下,接收到有问题的请求正文?请求正文不应大于几百个字节。我已经每1秒监控一次网络流量,并且它永远不会高于1Mbit / s,并且我看不到任何rxerrs或rxdorps,考虑到服务器处于1Gbit / s线路上,这听起来并不像HopelessN00b发布了。可能只是某些用户连接不良的情况?

对于每小时的峰值(它们似乎有点漂移,在上图中,它们是每小时经过33分钟,现在是过去12分钟),我试图查看是否有任何周期性运行(克朗等),但一无所获。PHP垃圾收集每小时运行两次,但不是在高峰时运行,我仍然尝试禁用它,但这没什么区别。

我将dstat与--top-cpu和top一起使用,以查看峰值时的进程,所有显示的内容是apache努力工作了几秒钟,但没有其他进程使用显着的cpu。

我已经放大了尖峰图: 放大的请求响应时间

在我看来,Apache暂停了几秒钟,然后努力处理在暂停期间出现的请求。是什么原因导致这种停止,还是我误解了?


1
我想在请求中发布一些图表,但是我的代表太低了。
里昂

Answers:


4

我要注意的第一件事是,查看您的第一个图表,似乎每小时都有一个速度下降(发生在每小时之后40分钟左右),这可能是造成此问题的原因。您应该查看OS /数据库上的任务计划程序。

根据您提供的数据,我的下一步将是查看响应时间的频率(Y轴上的响应数与X上的持续时间),但仅包括显示超时的网址(最好一次包含一个网址) )。在典型的系统上,这应该遵循正态分布或泊松分布-超时的请求可能只是尾巴的一部分-在这种情况下,您需要集中精力进行常规调整。OTOH如果分发是双峰的,那么您需要在代码中的某处寻找竞争。


感谢您的答复。我正在调查可能导致每小时速度变慢的原因。同时,我对已有数据进行了频率绘图。这只是存在超时问题的URL之一(但其他URL看起来非常相似):leela.kikora.no/apache_hist_show.png与少于10秒的URL相比,其超时量很小。好像它可能不是尾巴的一部分。但另一方面,由于它们代表了需要50秒钟以上才能完成的任何事情,因此看起来应该像这样。
利昂

3

基于您每天收到大量请求并且似乎仅在高峰时段(根据您发布的图片)超时的事实,我对此有另一种想法。

Server Fault博客上有一个帖子,Per Second Measurements Don't Cut It ...这些请求中是否有一些正在遇到ServerFault团队遇到的同一问题?

我们发现我们经常在1 Gbit / s接口上以10-30 MBit / s的速率丢弃数据包,这会损害我们的性能。这是因为10-30 MBit / s速率实际上是每5分钟转换为1秒钟速率的传输位数。当我们深入研究Wireshark并使用一毫秒的IO绘图时,我们看到我们经常会爆破所谓的1 Gbit / s接口的1毫秒每毫秒速率。


有趣的是,我来看看。我启用了mod_reqtimeout并将其设置为RequestReadTimeout标头= 20-40,minrate = 500和RequestReadTimeout正文= 10,minrate = 500,现在几乎所有超时都在10秒发生。我的意思是,请求主体花费的时间太长(主体最多不应超过几百个字节),因此我的某些用户连接不良或您所说的服务器端存在一些拥塞。
利昂
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.