AWS EC2 Alarmas de CPU alta que se apagan

Question

Tengo una instancia micro EC2 que ejecuta Windows 2008 R2. Últimamente he estado recibiendo muchas alarmas de CPU altas y, cuando inicio sesión en la consola de administración de AWS, veo que mi CPU está prácticamente fijada al 100%. Sin embargo, si inicio sesión en la instancia y retiro el administrador de tareas, mi CPU parece estar prácticamente inactiva. He dejado el administrador de tareas abierto durante un tiempo y tomé esta captura de pantalla que muestra las diferencias entre los informes de AWS y el aspecto de mi instancia. Sugerencias?

(https://s3.amazonaws.com/caskerdbbucket/public/cpu.png)

PS: se establece la velocidad de actualización en el administrador de tareas para "Bajo"

Answer 1

Los datos expuestos por el sistema operativo es a menudo insuficiente o engañosa en entornos virtualizados como Amazon EC2 y el porcentaje informado depende de su tipo de instancia y la utilización subyacente del núcleo del procesador (que generalmente no coincide con el hardware virtualizado que le presenta el hipervisor), entre otras cosas, lo que está viendo probablemente sea causado por el robo de CPU respectivo tiempo como se expone en la mayoría de las herramientas de supervisión de Unix/Linux relacionadas hoy en día (pero no en Windows, lamentablemente, vea mi pregunta Is there a Windows equivalent of Unix 'CPU steal time'? para obtener más información sobre este problema) - ver p. columnas% robar o st en sar o top:

st - Roba Tiempo
La cantidad de CPU 'robado' de esta máquina virtual por el hipervisor para otras tareas (tales como la ejecución de otro virtual máquina).

La entrada de blog EC2 monitoring: the case of stolen CPU proporciona una buena exploración y la ilustración de este tema:

Cuando la parte superior comando muestra el 40% de la CPU ocupado, pero CloudWatch indica que el servidor está al máximo al 100% - de qué lado ¿Usted toma? La respuesta es sencilla (CloudWatch es correcto, no es superior) [...]

CPU robar tiempo es particularmente frecuente para el tipo de instancia EC2 t1.micro está utilizando, que puede conseguir en gran medida estrangulado por definición (normalmente ~ 97% robar tiempo!), ver Micro Instances de una extensa explicación e ilustración del concepto - específicamente, la sección When the Instance Uses Its Allotted Resources estados:

esperamos su aplicación a consumir sólo una cierta cantidad de CPU recursos en un período de tiempo. Si la aplicación consume más de los recursos de CPU asignados a su instancia, , limitamos temporalmente la instancia , por lo que opera a un nivel de CPU bajo. Si su instancia continúa para usar todos sus recursos asignados, su rendimiento se degradará. Nos aumentará el tiempo que limitamos su nivel de CPU, lo que aumenta el tiempo antes de que la instancia pueda estallar de nuevo.[el énfasis es mío]

En consecuencia, es posible que ya no caben en el perfil de uso de la CPU sostenible para las instancias micro y cualquiera que necesite ajustar su carga de trabajo o cambiar a otro tipo de instancia.

Answer 2

Tuve el mismo problema y me llevó mucho tiempo encontrar una solución. En internet no encontré mi caso, entonces lo comparto.

Descubrí en la lista de eventos que se registraron muchos intentos de inicio de sesión fraudulentos. El administrador de tareas en esa situación informaba del 30-40% del uso de la CPU (Cloud Watch 100%) y en la lista de procesos se veían algunos winlogon.exe. Después de cambiar el puerto de Escritorio remoto (3389 es el valor predeterminado) no tuve más problemas. Ahora, el uso de la CPU en Cloud Watch es de un 34-35%.

Espero que esto ayude.