4 votos

Extraño proceso de tiempo de CPU de la salida de Ubuntu en virtud de Amazon EC2

Acabo de empezar un gran ejemplo el uso de ami-fa01f193 AMI. Cuando yo uso ps aux, un montón de procesos aleatorios se muestran los números grandes para el tiempo de CPU utilizado. Se parece a algún tipo de desbordamiento. ¿Alguien vea el antes y cómo puedo solucionarlo?

Aquí se muestra un ejemplo de salida:

  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]

2voto

KnipSter Puntos 389

TL/DR: Problema Conocido con Ubuntu 10.04 LTS en Amazon EC2 Nehalem instancias


De acuerdo a Mike Heffner (de Librato del Silverline):

Durante las conversaciones con otros tech las empresas que hemos aprendido de un problema cuando ejecuta el Ubuntu 10.04 LTS liberación en ciertos servidores de Amazon EC2 -- el mismo entorno como nuestra base de datos servidores. El problema parecía ser activa cuando el lanzamiento de Ubuntu 10.04 LTS liberación en hipervisores se ejecutan en procesadores Intel ® Xeon ® Serie 55xx (Nehalem) Cpu. Por ejemplo, algunos Cassandra usuarios informaron que los nodos completamente de congelamiento para los períodos prolongados de tiempo. Nosotros identificó que sólo vimos la gran CPU picos en nuestro sistema de back-end de la CPU gráficos cuando se había puesto en marcha una E5507 instancia de copia de seguridad.

Mike recomienda las siguientes soluciones, mientras que un parche para el kernel de Ubuntu 10.01: Hay una serie de enfoques, los usuarios pueden tomar para evitar ser afectados por este:

  1. Actualizar a una nueva versión de Ubuntu, por ejemplo, Ubuntu 10.10. Desde Ubuntu 10.04, el Xen parches mejor integrado en el kernel evitar el requisito de migración a 2.6.32. Los usuarios han informado de que el proceso original bloqueos no se producen con el Ubuntu 10.10 imágenes.

  2. Para los usuarios con entornos en la actualidad depende de la de Ubuntu 10.04 medio ambiente (todavía tenemos algunos de nosotros) hemos modificado nuestro OPS secuencias de comandos para lanzar fuera de las instancias que arranque con el Nehalem Cpu y reaprovisionar hasta obtener una E5430 de la máquina. Hemos notado que en algunos AZs vemos más Nehalem que en otros, lo que probablemente apunta a AZs con el más reciente hardware implementaciones. Obviamente este enfoque no es sostenible en un todo como más los usuarios que buscan la mayor E5430 Cpu y Amazon más invierte en la arquitectura Nehalem, por lo que estamos trabajando activamente para migrar nuestras 10.04 sistemas 10.10.

  3. Para usuarios avanzados, la construcción de una costumbre 2.6.32 núcleo que contiene el conjunto de parches desde el informe de error es una opción. También hay algunos núcleos personalizados y Ami en este informe de error que los usuarios han reportado éxito con.

0voto

ChrisW Puntos 43

Algo similar me pasó a mí en un servidor Centos. Un completo reinicio en frío se ha solucionado el problema. Por supuesto, no sé cómo se podría ir sobre un reinicio en frío en una máquina virtual, aunque...

En un recién reiniciado el servidor ¿por qué la CPU tiempo de ejecución de los procesos a ser enorme?

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: