所以…我在电子邮件服务器上看到一些非常奇怪的加载问题。 上午8点到9点（巧合的是，当人们开始工作），但大约上午11点左右下降。 CPU使用率保持正常，我有大量的可用内存，不交换。 昨天我们有一个非常高的爱荷华州（49.75），有一个非常高的负荷（40），今天我们只有“11-12负荷爱荷华州在3-4之间。
所有的迹象都指出imapd是罪魁祸首（courier-imap），因为当我停下来的时候，负载突然开始下降，在2-3分钟内恢复正常。 我确实有大约40-60人在跑步。 我们使用thunderbird，每个打开5个连接，在大多数工作站上我把它降低到1，这有点帮助（负载下降到5-7），然后…整个服务器在上午11点左右恢复正常。
我仍然有〜30个imapds运行，但与完全正常的负载（0.2和0.4之间）。 所以…我不太明白为什么会这样，因为从逻辑上讲，如果这是问题的原因，它应该更高。
这是一个Linode 1080 VPS和1gig ram。
（chkrootkit / rkhunter显示没有什么不寻常的。）
如果您使用VPS，则与其他用户共享IO带宽，CPU时间和内存带宽，这些用户对VPS不可见。
我有信心说在物理机器上托pipe的另一个domU正在消耗大量的这些资源中的一个或多个（很可能是IO）。
如果你使用iostat -x你可能会发现你的服务时间非常波动，这就解释了为什么你的负载平均值是尖峰的，这是由于磁盘IO上的进程被阻塞了。
据我了解，加载* nix系统意味着“等待运行的进程数量”。 这并不一定意味着他们正在等待CPU。 他们可能正在等待磁盘访问，或者networking连接完成。
例如，我曾经pipe理一个负载开始超过80的系统，偶尔会使系统爬行。 结果是因为外部LDAP服务器发生了故障，而本地系统正在为客户端进行身份validation请求。
如果你的CPU和iowait看起来不错，我会寻找你的应用程序可能导致exception高负载读数的罪魁祸首的networking依赖性。
就像第一张海报，这可能是IO。 我实际上在我的vserver上有相同的设置，经常看到相同的问题。 问题是像vserver这样的虚拟服务器的当前容器方法不能有效地分离IO。 如果您有兴趣，请参阅第13页的白皮书。 http://www.cs.princeton.edu/~mef/research/vserver/paper.pdf