我们有几个 Web 服务器通过 Amazon AMI 在 Amazon (ec2) c1.xlarge 上运行。
这些服务器彼此重复，运行完全相同的硬件和软件。每个服务器的规格如下：
- 7 GB 内存
- 20 个 EC2 计算单元（8 个虚拟核心，每个核心有 2.5 个 EC2 计算单元）
- 1690 GB 实例存储
- 64 位平台
- I/O 性能：高
- API 名称：c1.xlarge
几周前，我们yum upgrade在一台服务器上运行了。从这次升级开始，升级后的服务器开始显示高平均负载。不用说，我们没有更新其他服务器，而且在我们了解此行为的原因之前，我们不能这样做。
奇怪的是，当我们比较使用top或 的服务器时iostat，我们找不到高负载的原因。请注意，我们已将流量从“有问题的”服务器转移到其他服务器，这使得“有问题的”服务器在请求方面不那么拥挤，但它的负载仍然较高。
您知道这可能是什么吗，或者我们还可以在哪里检查？
#
# 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.00s w
#
# 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.00s w
#
# 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
答案1
AWS 过度竞争其 VM 服务器；他们假设并非每个人都会消耗分配给他们的所有资源，因此亚马逊可以从部署的每台硬件中赚取更多钱。因此，您可以拥有两个运行性能模式截然不同的完全相同的系统。与升级的关联可能是巧合。
关于您的诊断数据的说明：您确实希望输出sar -q帮助您诊断此类问题。 iostat实际上仅检查问题可能来源的一小部分。
答案2
另外，不要一直盯着负载。这很棘手。您的 I/O 状态和 CPU 状态更容易读取，也不太可能欺骗您。
举个例子：建立 10 个 nfs-mount。关闭 nfs-server。现在您的机器上有 10 个（多一点）负载，并且没有 I/O 或 CPU 使用率。
您的 nfs-mounts 想知道 nfs-server 何时恢复。因此，它们将自己放入运行队列，所有十个。当调度程序轮到它们时，它们会检查 nfs-server 是否恢复，这需要几微秒的时间，由于它仍然处于关闭状态，它们会再次将自己放回运行队列。运行队列中的十个程序负载为 10.0
答案3
冒着“我也有同样的问题”的风险，我们在 EC2 上也看到了同样的问题。这不仅仅是一个过度使用的问题——问题似乎仅限于 3.2.20 而非 3.2.12 的实例（在我们的例子中是 XL）。
在我们的案例中，这基本上是幻象负载——我们看到 3.2.20 实例的平均负载约为 0.75；3.2.12 实例的平均负载接近 0.01。然而，我们并不确信这些实例真的比其他实例慢。