Я только что запустил большой экземпляр, используя ami-fa01f193 AMI. Когда я использую ps aux, группа случайных процессов будет показывать ОГРОМНЫЕ числа для используемого процессорного времени. Похоже на переполнение какое то. Кто-то видел это раньше и как мне это исправить?
Вот пример вывода:
PID TTY STAT TIME COMMAND
1 ? Ss 0:00 /sbin/init
2 ? S 0:00 [kthreadd]
3 ? S 0:00 [migration/0]
4 ? S 17179869:11 [ksoftirqd/0]
5 ? S 0:00 [watchdog/0]
6 ? S 17179869:11 [events/0]
7 ? S 0:00 [cpuset]
8 ? S 0:00 [khelper]
9 ? S 0:00 [netns]
10 ? S 0:00 [async/mgr]
11 ? S 0:00 [xenwatch]
12 ? S 0:00 [xenbus]
14 ? S 0:00 [migration/1]
15 ? S 17179869:11 [ksoftirqd/1]
16 ? S 0:00 [watchdog/1]
17 ? S 17179869:11 [events/1]
18 ? S 0:00 [sync_supers]
19 ? S 0:00 [bdi-default]
TL / DR: известная проблема с Ubuntu 10.04 LTS на инстансах Amazon EC2 Nehalem
В соответствии с Майк Хеффнер (из Silverline Librato):
Во время разговоров с другими технологическими компаниями мы узнали о проблеме при запуске выпуска Ubuntu 10.04 LTS на определенных серверах Amazon EC2 - той же среде, что и наши внутренние серверы. Проблема, похоже, возникла при запуске выпуска Ubuntu 10.04 LTS на гипервизорах, работающих на процессорах Intel Xeon Series 55xx (Nehalem). Например, некоторые пользователи Cassandra сообщали, что узлы полностью зависают на длительные периоды времени. Мы определили, что наблюдали большие скачки ЦП на графиках ЦП нашей серверной системы только тогда, когда запускали инстанс с поддержкой E5507.
Майк рекомендует следующие обходные пути при установке патча ядра для Ubuntu 10.01: Существует ряд подходов, которые пользователи могут предпринять, чтобы избежать этого:
Обновитесь до более новой версии Ubuntu, например, Ubuntu 10.10. Начиная с Ubuntu 10.04, исправления Xen лучше интегрированы в ядро, что позволяет избежать необходимости их резервного копирования на версию 2.6.32. Пользователи сообщают, что исходные блокировки процесса не происходят с образами Ubuntu 10.10.
Для пользователей со средами, в настоящее время зависящими от среды Ubuntu 10.04 (у нас все еще есть некоторые из них), мы изменили наши сценарии OPS, чтобы исключить экземпляры, которые загружаются с процессорами Nehalem, и проводить повторную подготовку, пока мы не получим машину E5430. Мы заметили, что в некоторых зонах доступности мы видим больше зон Nehalem, чем в других, что, вероятно, указывает на зоны доступности с более поздним развертыванием оборудования. Очевидно, что такой подход в целом не является устойчивым, поскольку все больше пользователей ищут старые процессоры E5430, а Amazon продолжает инвестировать в архитектуру Nehalem, поэтому мы активно работаем над миграцией наших систем 10.04 на 10.10.
Для опытных пользователей: создание собственного ядра 2.6.32, содержащего набор исправлений из отчет об ошибке это вариант. В этом отчете об ошибке также есть несколько пользовательских ядер и AMI, с которыми пользователи сообщили об успехе.
Подобное случилось со мной на сервере Centos. Полная холодная перезагрузка устранила проблему. Конечно, я не знаю, как бы вы поступили с холодной перезагрузкой виртуальной машины ...
Почему на недавно перезагруженном сервере время выполнения процессов ЦП может быть огромным?