抱歉，帖子标题含糊不清，总结以下内容有点复杂，毕竟，正如标题所示，没有解释。无论如何，借口够多了……
今天早上我发现我的网站运行速度非常慢，这种情况通常不会发生，所以我显然正在尝试找出问题的原因。我知道我最近没有安装或更改任何东西，我首先要检查的是资源使用情况统计数据，这些数据没有显示任何异常：
load average: 0.35, 0.34, 0.36
检查了大约半个小时（在此期间用户报告了断电情况）后，结果显示没有任何超过 1 的数据。所以这不是“传统负载”。所以我正在寻找其他潜在原因。
顶部也没有显示出任何异常：
top - 08:34:34 up 1:33, 1 user, load average: 0.30, 0.36, 0.35
Tasks: 146 total, 1 running, 145 sleeping, 0 stopped, 0 zombie
Cpu0 : 6.6%us, 1.3%sy, 0.0%ni, 91.1%id, 0.7%wa, 0.0%hi, 0.3%si, 0.0%st
Cpu1 : 0.0%us, 0.0%sy, 0.0%ni, 99.3%id, 0.7%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu2 : 0.0%us, 0.3%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu3 : 0.3%us, 0.3%sy, 0.0%ni, 99.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 4016884k total, 1367624k used, 2649260k free, 5324k buffers
Swap: 3919840k total, 0k used, 3919840k free, 769024k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2593 apache 15 0 446m 66m 40m S 7.6 1.7 1:13.64 httpd
2450 mysql 15 0 257m 48m 5976 S 0.3 1.2 4:20.51 mysqld
9734 root 15 0 12740 1296 932 R 0.3 0.0 0:00.24 top
1 root 18 0 10348 752 628 S 0.0 0.0 0:04.91 init
2 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/0
3 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/0
4 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/0
5 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/1
然后我开始查看网络，以下命令（我从有关 DDOS 攻击的 SF 问题中获取）：
netstat -n|grep :80|cut -c 45-|cut -f 1 -d ':'|sort|uniq -c|sort -nr|more
给出：
534
5 1.1.1.1
4 2.2.2.2
4 3.3.3.3
3 4.4.4.4
2 5.5.5.5
2 6.6.6.6
2 7.7.7.7
1 8.8.8.8
1 9.9.9.9
1 10.10.10.10
1 11.11.11.11
IP 地址已编辑
那里似乎也没有什么异常，尽管我不确定 534 是什么意思。为了保险起见，我还重新启动了服务器（使用 Windows 这么长时间后习惯性的重新启动 ;)），但这没有任何变化。
所以现在我发现自己不知所措，我无法解释这里发生了什么，这当然意味着我无法解决它。
服务器详细信息 这是专用服务器，具有以下规格：
- 四核 AMD Opteron(tm) 处理器 1381
- 4GB 内存
该站点通过带有 MySQL 后端的 Apache 来服务器 PHP 页面（仅限 vbulletin），我还运行 APC 作为操作码缓存器。
编辑-更多信息 可能有用，也可能没用……
使用 Firefox 中的 Firebug，我一直在查看页面的加载时间。似乎发生的情况是，一个随机资源（有时是图像、JS 文件或 CSS 文件）需要花费过多的时间才能完成接收。请求在几毫秒内完成，但接收有时需要一分钟以上。然而，它是一种随机资源，我发出的每个请求都有不同的资源，需要很长时间才能返回。我没有为这些资源设置任何缓存等，这些资源通过文件系统中的 apache 正常提供。
编辑 iostat 的输出：
Linux 2.6.18-164.11.1.el5 12/10/2010
avg-cpu: %user %nice %system %iowait %steal %idle
4.66 0.00 2.08 0.84 0.00 92.42
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 12.48 78.48 144.52 1008089 1856500
sda1 0.43 2.52 6.95 32354 89224
sda2 0.01 0.11 0.00 1356 0
sda4 0.00 0.00 0.00 10 0
sda5 0.48 5.33 1.61 68413 20706
sda6 11.57 70.51 135.97 905732 1746570
sdb 12.43 78.57 144.52 1009340 1856500
sdb1 0.43 2.24 6.95 28768 89224
sdb2 0.00 0.08 0.00 1068 0
sdb4 0.00 0.00 0.00 10 0
sdb5 0.45 5.35 1.61 68729 20706
sdb6 11.53 70.88 135.97 910533 1746570
md1 0.91 4.72 5.96 60666 76520
md6 14.70 141.37 126.26 1815945 1621898
md5 0.57 10.65 1.05 136822 13474
编辑
如果我给你们这个网站的 URL，可能会有用：
答案1
好吧，如果问题发生在静态文件上，那很好，因为至少你知道要开始查看 Apache。你可能想要使用调试和分析工具来查看到底出了什么问题。假设你正在谈论 Linux 系统，这strace可能是你想要的工具。使用-f和-c选项，它将跟踪所有分叉的子进程并总结每个系统调用所花费的时间。这应该可以帮助你找出问题所在。
停止 Apache，然后通过 strace 重新启动它：
strace -cf /usr/sbin/httpd
（strace 确实有一个-p选项可以跟踪现有进程的 pid，但即使使用-f它也无法跟踪在调用 strace 之前分叉的子进程。）
让它运行一段时间，在运行时对网站进行重击，直到您可以触发减速几次，然后中断它。分析结果。
如果事实证明问题出在用户模式应用程序代码中而不是系统正在执行的某项操作，那么可以ltrace使用一个名为的配套程序来总结各种共享库调用所花费的时间。
这可能不言而喻，但也要检查您的服务器、系统和内核日志，以确保您没有看到任何意外故障或硬件事件。
答案2
您采取了哪些措施来排除客户端问题？最小的服务器负载和随机资源请求的间歇性延迟使我想排除实时文件扫描程序是罪魁祸首。这可能离题太远，但排除它应该很容易。