Никакая очевидная причина высокого среднего числа загрузки

AWS перегружает свои серверы виртуальных машин; они предполагают, что не все будут потреблять все выделенные им ресурсы, и поэтому Amazon может зарабатывать больше денег на единице развернутого оборудования. Таким образом, у вас могут быть две идентичные в остальном системы, работающие с совершенно разными шаблонами производительности. Корреляция с обновлением, вероятно, будет совпадением.

Примечание к вашим диагностическим данным: вы действительно хотите, чтобы вывод sar -q помог вам диагностировать такого рода проблемы. iostat на самом деле изучает лишь очень небольшую часть возможных источников проблемы.

Кроме того, не смотрите только на нагрузку. Это довольно вздорно. Ваши состояния ввода-вывода и состояния процессора легче читать, и они с меньшей вероятностью будут вам лгать.

Чтобы дать вам пример: сделайте десять nfs-mounts. Сними de nfs-server. Теперь ваш ящик загружен 10 (и немного) и не требует ввода-вывода или загрузки ЦП.

Ваши nfs-mounts хотят знать, когда nfs-сервер вернется. Итак, они поставили себя в очередь, все десять человек. Когда их очередь подходит к планировщику, они проверяют, вернулся ли nfs-сервер, что занимает микросекунды, и, поскольку он все еще не работает, они снова помещают себя в очередь выполнения.

At the risk of "me too" we see this exact same issue on EC2. This isn't simply an overcommit issue -- the problems seems to be confined to instance (XLs in our case) at 3.2.20 versus 3.2.12.

In our case, this is basically phantom load -- we see a load average of around .75 on the 3.2.20 instances; the 3.2.12 stay closer to 0.01. We are not convinced, however, that these instances are really slower than the others.