Processo estranho de saída de tempo da CPU no Ubuntu sob o Amazon EC2

Question

Acabei de iniciar uma instância grande usando a AMI am01-fa01f193. Quando eu uso ps aux, um monte de processos aleatórios mostrará números ENORMES do tempo de CPU usado. Parece algum tipo de estouro. Alguém viu isso antes e como eu corrijo isso?

Aqui está um exemplo de saída:

  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]

    

Answer 1

TL / DR: problema conhecido com o Ubuntu 10.04 LTS em instâncias do Amazon EC2 Nehalem

De acordo com Mike Heffner (da Silverline do Librato):

During conversations with other tech companies we learned of an issue when running the Ubuntu 10.04 LTS release on certain Amazon EC2 servers -- the same environment as our backend servers. The issue appeared to be triggered when launching the Ubuntu 10.04 LTS release on hypervisors running on Intel Xeon Series 55xx (Nehalem) CPUs. For example, some Cassandra users were reporting that nodes would completely freeze up for extended periods of time. We identified that we only saw the large CPU spikes in our backend system CPU graphs when we had launched an E5507 backed instance.

Mike recomenda as seguintes soluções alternativas enquanto um patch de kernel para o Ubuntu 10.01: Existem várias abordagens que os usuários podem adotar para evitar serem afetados por isso:

1. Atualize para uma versão mais recente do Ubuntu, por exemplo, o Ubuntu 10.10. Desde a Ubuntu 10.04, os patches Xen são melhor integrado no kernel evitando a exigência de backport -los para 2.6.32. Usuários relataram que os travamentos do processo original não ocorrem com o Ubuntu 10.10 imagens.

2. Para usuários com ambientes atualmente dependente do Ubuntu 10.04 ambiente (ainda temos alguns nós mesmos) modificamos nossa Scripts OPS para descartar instâncias que arrancar com os CPUs Nehalem e reprovision até chegarmos a um E5430 máquina. Nós notamos que em alguns AZs vemos mais Nehalem do que em outros, que provavelmente aponta para AZs com hardware mais recente implantações. Obviamente esta abordagem não é sustentável em um todo como mais usuários procuram o antigo E5430 CPUs e Amazon ainda investe em a arquitetura Nehalem, então estamos trabalhando ativamente para migrar 10,04 sistemas para 10,10.

3. Para usuários avançados, criando um personalizado 2.6.32 kernel que contém o patchset do relatório de erros é uma opção. Existem também alguns kernels personalizados e AMIs neste relatório de bug que usuários relataram sucesso com.

Answer 2

Uma coisa semelhante aconteceu comigo em um servidor Centos. Uma reinicialização completa e fria resolveu o problema. Claro, eu não sei como você faria uma reinicialização a frio em uma máquina virtual ...

Em um servidor recém-reinicializado, por que o tempo de processamento da CPU seria enorme?