为我们（Debian）LAMP集群设置的My Munin通知不断告知我，我们的生产机器上的负载一直处于危险的水平。 虽然全年的平均负荷一般在2到8之间，但过去一个月和过去一个月的负荷已经暴涨到了10,18，有时甚至是50-60。 尖峰一次只能持续5-10分钟，大约每2-3小时发生一次。 尖峰不会影响性能，因为我有一个脚本，当负载超过10时，会将stream量从服务器发送到镜像CDN。我已经查找与此时间范围相关的cron作业，但没有任何可以看到的情况导致这一点。 网站stream量也是正常的（我们每天接收约20万次访问）。 这个Web服务器依赖的MySQL数据库似乎正常运行。 该服务器的负载较低，性能较好。
我也试着想想在这个问题开始的时候我已经改变了什么，我真的想不出什么。
这可能不会继续下去。 也许在顶部的打印输出中有一条线索，我没有看到。
我如何着手寻找原因？
– 典型的顶部，当负载不峰值时：
top - 11:13:09 up 472 days, 25 min, 1 user, load average: 6.08, 4.29, 3.80 Tasks: 105 total, 1 running, 104 sleeping, 0 stopped, 0 zombie Cpu(s): 41.2%us, 5.8%sy, 0.0%ni, 49.5%id, 2.7%wa, 0.1%hi, 0.7%si, 0.0%st Mem: 3369592k total, 2166980k used, 1202612k free, 559504k buffers Swap: 2650684k total, 1892k used, 2648792k free, 1129116k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 32046 apache 15 0 36300 12m 9828 S 20 0.4 0:01.97 apache2 32679 apache 15 0 36568 13m 10m S 19 0.4 0:01.69 apache2 31441 apache 15 0 36616 13m 10m S 19 0.4 0:04.13 apache2 31477 apache 15 0 36596 13m 9.8m S 15 0.4 0:01.99 apache2 31993 apache 15 0 36876 16m 12m S 12 0.5 0:02.01 apache2 31782 apache 15 0 36836 14m 10m S 8 0.4 0:02.17 apache2 32198 apache 15 0 36536 13m 10m S 7 0.4 0:01.59 apache2 880 apache 15 0 36508 9708 6236 S 7 0.3 0:00.42 apache2 31945 apache 17 0 36876 16m 13m S 5 0.5 0:03.17 apache2 32197 apache 16 0 36636 10m 7504 S 5 0.3 0:02.70 apache2 32326 apache 15 0 37024 11m 7632 S 5 0.3 0:02.15 apache2 32565 apache 15 0 37280 13m 9.8m S 5 0.4 0:03.75 apache2 32676 apache 15 0 36896 16m 12m S 4 0.5 0:00.95 apache2 32678 apache 15 0 36536 12m 9692 S 4 0.4 0:02.27 apache2 974 apache 16 0 37064 9888 6016 D 4 0.3 0:00.13 apache2 32150 apache 16 0 36832 13m 10m S 3 0.4 0:01.74 apache2 31780 apache 16 0 36848 11m 7660 S 3 0.3 0:02.87 apache2 当我们加注的时候，这里是顶尖的：
top - 15:25:22 up 474 days, 4:37, 1 user, load average: 78.73, 50.20, 24.79 Tasks: 250 total, 4 running, 244 sleeping, 0 stopped, 2 zombie Cpu(s): 36.5%us, 4.7%sy, 0.0%ni, 56.4%id, 2.0%wa, 0.1%hi, 0.3%si, 0.0%st Mem: 3369592k total, 2099904k used, 1269688k free, 553840k buffers Swap: 2650684k total, 5104k used, 2645580k free, 729252k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 27716 apache 15 0 43612 20m 9.8m S 20 0.6 0:01.95 apache2 16782 apache 16 0 39460 19m 13m R 19 0.6 0:04.61 apache2 19701 apache 15 0 39232 16m 10m S 17 0.5 0:03.18 apache2 19677 apache 16 0 39208 15m 9956 R 12 0.5 0:05.03 apache2 16760 apache 15 0 36620 16m 13m S 8 0.5 0:06.35 apache2 19798 apache 15 0 36564 13m 9988 S 6 0.4 0:02.76 apache2 20325 apache 15 0 36616 13m 9704 S 6 0.4 0:02.11 apache2 19699 apache 15 0 36860 15m 12m S 5 0.5 0:03.10 apache2 15109 apache 15 0 36624 16m 13m S 4 0.5 0:05.97 apache2 15101 apache 15 0 36592 13m 10m S 3 0.4 0:08.96 apache2 15112 apache 15 0 36612 16m 13m S 3 0.5 0:07.57 apache2 20204 apache 15 0 44612 21m 9.9m S 3 0.6 0:03.55 apache2 19624 apache 15 0 36588 13m 10m S 3 0.4 0:02.00 apache2 20151 apache 15 0 36616 16m 13m S 3 0.5 0:02.14 apache2 26252 apache 15 0 37072 13m 9m S 3 0.4 0:01.09 apache2 19805 apache 15 0 36472 16m 12m S 2 0.5 0:03.68 apache2 20163 apache 15 0 36640 13m 10m S 2 0.4 0:02.50 apache2 27260 apache 18 0 44292 20m 9328 S 2 0.6 0:02.08 apache2 29149 apache 15 0 36172 11m 8744 S 2 0.4 0:00.69 apache2 20315 apache 15 0 36360 15m 12m S 2 0.5 0:02.06 apache2 29148 apache 16 0 36184 8872 5644 S 2 0.3 0:00.08 apache2
Loadavg并没有告诉你真的，你的系统是否performance不佳; 这是一个非常通用的度量标准，它描述了系统的繁忙程度，其中繁忙定义为当前执行或等待执行cpu指令的进程数的索引。 在一个八核心系统上，工作负载由大量短暂的进程（比如说一个web服务器）来描述，一个50以上的loadavg可能甚至不会引起我的注意。
你能把这些尖峰与你的apache日志关联起来，看看在峰值期间响应时间是否受损？ 在尖峰期间你只是提供更多的请求吗？ 你是否保留了像iowait和用户vs系统cpu的统计数据，并且它们是否相关？ 另外一个提到交换的海报是正确的：交换可能导致进程堆积，因为内存访问速度降低到磁盘速度，这可能导致更高的loadavg，因为进程停滞不前。
这些都是要调查的事情; 更多数据和历史数据，可以帮助您解决这个问题。 希望这可以帮助; 祝你好运！
根据新上线的系统pipe理员，负载变得如此之高，因为我们最近一直在持续打击我们的带宽分配能力（不确定是入站还是出站）。 这个问题的一些答复是正确的，因为这根本不是服务器问题的标志。 这是一个networking问题，新的请求必须等待带宽清理才能继续进行 – 因此，高负载（延迟）。 无论如何，我们最近已经搬到了一个拥有更大带宽分配的新数据中心。 感谢大家！
你在后端使用的是Memcached吗？ TTL是否在这个时间范围内到期？
当负载超过100％时性能是否受到影响？ 在多核CPU中，这很可能是正常的。
PS它也看起来像你陷入你的SWAP分配; 我会看看这个。
如果您的Apache应用程序正在针对数据库后端运行，那么很可能您正在运行数据库端的locking/争用问题。 你经常产生的（或重用的）apache进程会发现自己正在等待长时间运行的数据库请求来完成，从而累积到很高的数量。
所以检查你的数据库服务器是否会镜像加载图片。 如果你碰巧使用MySQL（在LAMP中是M，不是吗？），你应该考虑使用mysql-snmp来获得更详细的报告。