我们有几台在亚马逊（ec2）c1.xlarge上通过Amazon AMI运行的networking服务器。
服务器是相互重复的，运行完全相同的硬件和软件。 每个服务器规格是：
几个星期前，我们已经在其中一台服务器上进行了yum upgrade 。 从此升级开始，升级后的服务器开始显示高负载平均值。 不用说，我们没有更新其他服务器，我们不能这样做，直到我们理解这种行为的原因。
奇怪的是，当我们比较使用top或iostat的服务器时，我们找不到高负载的原因。 请注意，我们已经将stream量从“有问题的”服务器转移到其他服务器，这使得“问题”服务器在请求方面不那么拥挤，而且他的负载仍然较高。
你有什么想法是什么，或者我们可以检查什么？
# # proper server # w command # 00:42:26 up 2 days, 19:54, 2 users, load average: 0.41, 0.48, 0.49 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT pts/1 82.80.137.29 00:28 14:05 0.01s 0.01s -bash pts/2 82.80.137.29 00:38 0.00s 0.02s 0.00sw # # proper server # iostat command # Linux 3.2.12-3.2.4.amzn1.x86_64 _x86_64_ (8 CPU) avg-cpu: %user %nice %system %iowait %steal %idle 9.03 0.02 4.26 0.17 0.13 86.39 Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn xvdap1 1.63 1.50 55.00 367236 13444008 xvdfp1 4.41 45.93 70.48 11227226 17228552 xvdfp2 2.61 2.01 59.81 491890 14620104 xvdfp3 8.16 14.47 94.23 3536522 23034376 xvdfp4 0.98 0.79 45.86 192818 11209784 # # problematic server # w command # 00:43:26 up 2 days, 21:52, 2 users, load average: 1.35, 1.10, 1.17 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT pts/0 82.80.137.29 00:28 15:04 0.02s 0.02s -bash pts/1 82.80.137.29 00:38 0.00s 0.05s 0.00sw # # problematic server # iostat command # Linux 3.2.20-1.29.6.amzn1.x86_64 _x86_64_ (8 CPU) avg-cpu: %user %nice %system %iowait %steal %idle 7.97 0.04 3.43 0.19 0.07 88.30 Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn xvdap1 2.10 1.49 76.54 374660 19253592 xvdfp1 5.64 40.98 85.92 10308946 21612112 xvdfp2 3.97 4.32 93.18 1087090 23439488 xvdfp3 10.87 30.30 115.14 7622474 28961720 xvdfp4 1.12 0.28 65.54 71034 16487112 # # sar -q proper server # Linux 3.2.12-3.2.4.amzn1.x86_64 (***.com) 07/01/2012 _x86_64_ (8 CPU) 12:00:01 AM runq-sz plist-sz ldavg-1 ldavg-5 ldavg-15 12:10:01 AM 13 194 0.41 0.47 0.51 12:20:01 AM 7 188 0.26 0.39 0.49 12:30:01 AM 9 198 0.64 0.49 0.49 12:40:01 AM 9 194 0.50 0.48 0.48 12:50:01 AM 7 191 0.44 0.36 0.41 01:00:01 AM 10 195 0.76 0.64 0.51 01:10:01 AM 7 175 0.41 0.58 0.56 01:20:01 AM 8 183 0.38 0.42 0.49 01:30:01 AM 8 186 0.43 0.38 0.44 01:40:01 AM 8 178 0.58 0.46 0.43 01:50:01 AM 9 185 0.47 0.45 0.45 02:00:01 AM 9 184 0.38 0.47 0.48 02:10:01 AM 10 184 0.50 0.51 0.50 02:20:01 AM 13 200 0.37 0.45 0.48 Average: 9 188 0.47 0.47 0.48 02:28:42 AM LINUX RESTART 02:30:01 AM runq-sz plist-sz ldavg-1 ldavg-5 ldavg-15 02:40:01 AM 9 151 0.55 0.55 0.37 02:50:01 AM 7 163 0.54 0.48 0.42 03:00:01 AM 9 164 0.35 0.43 0.42 03:10:01 AM 10 168 0.31 0.36 0.40 03:20:01 AM 8 170 0.27 0.34 0.39 03:30:01 AM 8 167 0.50 0.55 0.48 03:40:01 AM 8 153 0.22 0.36 0.43 03:50:01 AM 7 165 0.38 0.38 0.41 04:00:01 AM 8 169 0.70 0.45 0.42 04:10:01 AM 8 160 0.58 0.46 0.43 04:20:01 AM 8 166 0.31 0.35 0.40 04:30:01 AM 9 166 0.17 0.33 0.38 04:40:01 AM 9 159 0.13 0.29 0.37 04:50:01 AM 12 170 0.36 0.28 0.32 05:00:01 AM 7 162 0.16 0.22 0.28 05:10:01 AM 6 163 0.51 0.43 0.36 05:20:01 AM 8 162 0.50 0.45 0.41 05:30:01 AM 10 170 0.30 0.32 0.36 05:40:01 AM 7 167 0.37 0.32 0.33 05:50:01 AM 8 166 0.48 0.44 0.38 06:00:01 AM 12 177 0.41 0.41 0.40 06:10:01 AM 8 166 0.47 0.44 0.42 06:20:01 AM 9 177 0.32 0.38 0.40 06:30:01 AM 5 166 0.29 0.37 0.40 06:40:01 AM 8 165 0.57 0.41 0.40 Average: 8 165 0.39 0.39 0.39 # # sar -q problematic server # Linux 3.2.20-1.29.6.amzn1.x86_64 (***.com) 07/01/2012 _x86_64_ (8 CPU) 12:00:01 AM runq-sz plist-sz ldavg-1 ldavg-5 ldavg-15 12:10:01 AM 12 194 1.20 1.19 1.28 12:20:01 AM 7 200 0.95 1.26 1.34 12:30:01 AM 11 199 1.16 1.23 1.30 12:40:01 AM 7 200 0.96 1.03 1.18 12:50:01 AM 8 208 1.42 1.17 1.16 01:00:02 AM 8 201 0.91 1.09 1.16 01:10:01 AM 7 200 1.08 1.15 1.19 01:20:01 AM 9 200 1.45 1.25 1.23 01:30:01 AM 11 195 0.97 1.10 1.19 01:40:01 AM 7 188 0.78 1.05 1.16 01:50:01 AM 9 196 1.32 1.22 1.24 02:00:01 AM 12 206 0.96 1.17 1.22 02:10:01 AM 9 187 0.96 1.09 1.17 Average: 9 198 1.09 1.15 1.22 02:23:22 AM LINUX RESTART 02:30:01 AM runq-sz plist-sz ldavg-1 ldavg-5 ldavg-15 02:40:01 AM 9 160 1.12 1.16 0.87 02:50:01 AM 9 163 0.77 0.94 0.91 03:00:01 AM 7 162 1.03 1.10 1.03 03:10:01 AM 9 164 0.99 1.07 1.05 03:20:01 AM 8 171 1.08 1.11 1.07 03:30:01 AM 8 167 1.02 0.99 1.02 03:40:01 AM 5 158 1.20 1.06 1.05 03:50:01 AM 8 171 1.11 1.10 1.07 04:00:01 AM 7 162 1.12 1.10 1.10 04:10:01 AM 9 164 0.90 0.94 1.02 04:20:01 AM 7 169 0.90 1.08 1.10 04:30:01 AM 13 169 1.07 1.07 1.10 04:40:01 AM 11 166 0.95 1.12 1.13 04:50:01 AM 7 173 1.04 1.12 1.13 05:00:01 AM 7 166 1.26 1.20 1.19 05:10:01 AM 10 169 1.14 1.25 1.22 05:20:01 AM 10 170 0.98 1.12 1.19 05:30:01 AM 10 166 0.82 0.98 1.09 05:40:01 AM 11 171 1.18 1.16 1.11 05:50:01 AM 12 187 1.07 1.19 1.16 06:00:01 AM 9 171 1.27 1.17 1.16 06:10:01 AM 7 169 1.40 1.26 1.22 06:20:01 AM 8 171 0.91 1.12 1.19 06:30:01 AM 8 172 1.00 1.11 1.17 06:40:01 AM 9 177 1.02 1.10 1.15 Average: 9 168 1.05 1.10 1.10
AWS过度使用其VM服务器; 他们假设不是每个人都会消耗所有分配给他们的资源，所以亚马逊可以在部署硬件的单位上赚更多的钱。 因此，您可以拥有两个完全不同的性能模式的其他系统。 与升级的相关性可能是巧合。
关于您的诊断数据的说明：您确实希望sar -q的输出帮助您诊断这类问题。 iostat实际上只是研究问题的可能来源的一小部分。
另外，不要单独盯着负载。 这是相当诡异的。 你的I / O状态和CPU状态更容易阅读，不太可能骗你。
举个例子：make十个nfs-mounts。 把de nfs-server放下。 你的盒子现在有10（和一点）的负载，没有I / O或CPU的使用率说话。
你的nfs-mounts想要知道nfs-server何时回来。 所以他们把自己放在跑步队里，全部十人。 当他们轮到调度员时，他们检查nfs-server是否回来，这需要几微秒，而且由于它仍然停机，他们又把自己重新放在runqueue上。 runqueue中的十个程序的负载是10.0
冒着“我也是”的风险，我们在EC2上看到了这个完全相同的问题。 这不仅仅是一个过度使用的问题 – 这个问题似乎只限于3.2.20和3.2.12的实例（在我们的例子中是XL）。
在我们的情况下，这基本上是幻影负载 – 在3.2.20个实例中，我们看到平均负载为0.75。 3.2.12保持接近0.01。 然而，我们并不相信这些情况确实比其他情况慢。