Comprender el alto uso de la CPU informado por vManage para las plataformas de nube vEdge 5000/2000/1000/100B y vEdge
Contenido
Introducción
Este documento describe por qué puede ver un uso elevado de la CPU en las plataformas vManage para vEdge 5000/2000/1000/100B y vEdge Cloud a pesar de que el rendimiento de las plataformas sea normal sin que se informe un uso elevado de la CPU como se ve en la parte superior.
Comprender la alta utilización de la CPU que se informa en las plataformas de nube vEdge 5000/2000/1000/100B y vEdge
Con las versiones 17.2.x y posteriores, se puede observar un mayor consumo de memoria y CPU para las plataformas vEdge y vEdge Cloud. Esto se nota en el panel vManage para un dispositivo determinado. En algunos casos, esto también conduce a un mayor número de alertas y advertencias en vManage.
Explicación
El motivo del uso elevado de la CPU informado cuando el dispositivo funciona normalmente con normal, baja o sin carga se debe a un cambio en la fórmula utilizada para calcular el uso. Con las versiones 17.2, la utilización de la CPU se calcula en función del promedio de carga del estado del sistema show en el vEdge.
vManage muestra el uso de CPU en tiempo real para un dispositivo. Se extrae el promedio de 1 minuto [min1_avg] y el promedio de 5 minutos [min5_avg] basándose en los datos históricos. Cargar promedio, por definición, incluye varias cosas y no sólo ciclos de CPU que contribuyen al cálculo de utilización. Por ejemplo, el tiempo de espera de E/S, el tiempo de espera del proceso y otros valores se consideran cuando se presenta este valor para la plataforma. En este caso, ignora los valores mostrados para los estados de la CPU y los valores de la CPU en el comando top de vShell.
Aquí hay un ejemplo de cómo se calcula el uso de la CPU, que en realidad es el promedio de carga de 1 minuto, y se muestra en el panel vManage:
Cuando verifica la carga desde una CLI de vEdge, esto puede verse:
vEdge# show system status | include Load Load average: 1 minute: 3.10, 5 minutes: 3.06, 15 minutes: 3.05 Load average: 1 minute: 3.12, 5 minutes: 3.07, 15 minutes: 3.06 Load average: 1 minute: 3.13, 5 minutes: 3.08, 15 minutes: 3.07
Load average: 1 minute: 3.10, 5 minutes: 3.07, 15 minutes: 3.05
En este caso, la utilización de la CPU se calcula en función de la carga media / número de núcleos (vCPU). Para este ejemplo, el nodo tiene 4 núcleos. A continuación, el promedio de carga se convierte por un factor de 100 antes de dividirlo por el número de núcleos. Cuando calcula el promedio de carga de todos los núcleos y se multiplica por 100, obtiene un valor de ~310. Tome este valor y divida por 4 rendimientos, una lectura de CPU del 77,5%, que se alinea con el valor visto en el gráfico en tiempo real en vManage capturado alrededor del momento en que se recopiló el resultado de CLI y como se muestra en la imagen.
Para ver los promedios de carga y el número de núcleos de CPU en el sistema, el resultado de top se puede consultar desde vShell en el dispositivo.
En el ejemplo, el vEdge contiene 4 vCPU. El primer núcleo (Cpu0) se utiliza para Control (visto a través de la menor utilización de usuarios) mientras que los 3 núcleos restantes se utilizan para Datos:
top - 01:14:57 up 1 day, 3:15, 1 user, load average: 3.06, 3.06, 3.08 Tasks: 219 total, 5 running, 214 sleeping, 0 stopped, 0 zombie Cpu0 : 1.7%us, 4.0%sy, 0.0%ni, 94.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu1 : 56.0%us, 44.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu2 : 54.2%us, 45.8%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu3 : 59.3%us, 40.7%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 7382664k total, 2835232k used, 4547432k free, 130520k buffers Swap: 0k total, 0k used, 0k free, 587880k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 978 root 20 0 3392m 664m 127m R 100 9.2 1635:21 fp-um-2 692 root 20 0 3392m 664m 127m R 100 9.2 1635:18 fp-um-1 979 root 20 0 3392m 664m 127m R 100 9.2 1634:51 fp-um-3 694 root 20 0 1908m 204m 131m S 1 2.8 15:29.95 ftmd 496 root 20 0 759m 72m 3764 S 0 1.0 1:31.50 confd
Para obtener el número de CPU de la CLI de vEdge, se puede utilizar este comando:
vEdge# show system status | display xml | include total_cpu
<total_cpu_count>4</total_cpu_count>
Aquí se proporciona otro ejemplo del cálculo del valor mostrado en vManage en vEdge 1000. Después de emitir top desde vShell, l está interesado en mostrar la carga para todos los núcleos:
top - 18:19:49 up 19 days, 1:37, 1 user, load average: 0.55, 0.71, 0.73
Dado que un vEdge 1000 solo tiene un núcleo de CPU disponible, la carga informada aquí es del 55% (0,55*100).
Uso elevado de la CPU con proceso fp-um
A veces también puede notar desde arriba que el proceso fp-um se ejecuta en niveles altos y muestra hasta un 100% de CPU. Esto se espera en los núcleos de CPU que se utilizan para el procesamiento del plano de datos.
Del comando top mencionado anteriormente, 3 núcleos funcionan al 100% de la CPU y 1 núcleo muestra la utilización normal:
top - 01:14:57 up 1 day, 3:15, 1 user, load average: 3.06, 3.06, 3.08 Tasks: 219 total, 5 running, 214 sleeping, 0 stopped, 0 zombie Cpu0 : 1.7%us, 4.0%sy, 0.0%ni, 94.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu1 : 56.0%us, 44.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu2 : 54.2%us, 45.8%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu3 : 59.3%us, 40.7%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 7382664k total, 2835232k used, 4547432k free, 130520k buffers Swap: 0k total, 0k used, 0k free, 587880k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 978 root 20 0 3392m 664m 127m R 100 9.2 1635:21 fp-um-2 692 root 20 0 3392m 664m 127m R 100 9.2 1635:18 fp-um-1 979 root 20 0 3392m 664m 127m R 100 9.2 1634:51 fp-um-3 ...
Este primer núcleo (Cpu0) se utiliza para Control y los tres núcleos restantes para Datos. Como puede ver en la lista de procesos, el proceso fp-um utiliza esos recursos.
fp-um es un proceso que utiliza un controlador de modo de sondeo, lo que significa que coloca y sondea el puerto subyacente para los paquetes constantemente, de modo que pueda procesar cualquier trama tan pronto como se reciba. Este proceso gestiona el reenvío y es equivalente al reenvío de ruta rápida en vEdge 1000, vEdge 2000 y vEdge 100. Intel utiliza esta arquitectura de modo sondeo para un procesamiento eficiente de paquetes basado en el marco Data Plane Development Kit (DPDK). Debido a que el reenvío de paquetes se implementa en un loop ajustado, la CPU permanece en un 100% o casi en todo momento. Aunque esto se hace, no se introduce latencia a través de estas CPU, ya que se espera que esto ocurra.
Puede encontrar información de fondo sobre las encuestas DPDK aquí.
Las plataformas vEdge Cloud y vEdge 5000 utilizan la misma arquitectura de reenvío y muestran el mismo comportamiento a este respecto. Este es un ejemplo de un vEdge 5000 extraído de la salida superior. Tiene 28 núcleos, de los cuales 2 (Cpu0 y Cpu1) se utilizan para Control (como el vEdge 2000) y 26 para Datos.
top - 02:18:30 up 1 day, 7:33, 1 user, load average: 26.24, 26.28, 26.31 Tasks: 382 total, 27 running, 355 sleeping, 0 stopped, 0 zombie Cpu0 : 0.7%us, 1.3%sy, 0.0%ni, 98.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu1 : 0.7%us, 1.3%sy, 0.0%ni, 98.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu2 : 79.4%us, 20.6%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu3 : 73.4%us, 26.6%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu4 : 73.4%us, 26.6%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu5 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu6 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu7 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu8 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu9 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu10 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu11 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu12 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu13 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu14 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu15 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu16 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu17 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu18 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu19 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu20 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu21 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu22 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu23 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu24 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu25 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu26 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu27 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 32659508k total, 10877980k used, 21781528k free, 214788k buffers Swap: 0k total, 0k used, 0k free, 1039104k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2028 root 20 0 12.1g 668m 124m R 100 2.1 1897:21 fp-um-3 2029 root 20 0 12.1g 668m 124m R 100 2.1 1897:22 fp-um-4 2030 root 20 0 12.1g 668m 124m R 100 2.1 1897:12 fp-um-5 2031 root 20 0 12.1g 668m 124m R 100 2.1 1897:22 fp-um-6 2032 root 20 0 12.1g 668m 124m R 100 2.1 1897:22 fp-um-7 2034 root 20 0 12.1g 668m 124m R 100 2.1 1897:22 fp-um-9 2035 root 20 0 12.1g 668m 124m R 100 2.1 1897:21 fp-um-10 2038 root 20 0 12.1g 668m 124m R 100 2.1 1897:21 fp-um-13 2040 root 20 0 12.1g 668m 124m R 100 2.1 1897:23 fp-um-15 2041 root 20 0 12.1g 668m 124m R 100 2.1 1897:23 fp-um-16 2043 root 20 0 12.1g 668m 124m R 100 2.1 1897:22 fp-um-18 2045 root 20 0 12.1g 668m 124m R 100 2.1 1897:23 fp-um-20 2052 root 20 0 12.1g 668m 124m R 100 2.1 1897:18 fp-um-27 2033 root 20 0 12.1g 668m 124m R 100 2.1 1897:21 fp-um-8 2036 root 20 0 12.1g 668m 124m R 100 2.1 1897:21 fp-um-11 2037 root 20 0 12.1g 668m 124m R 100 2.1 1897:21 fp-um-12 2039 root 20 0 12.1g 668m 124m R 100 2.1 1897:09 fp-um-14 2042 root 20 0 12.1g 668m 124m R 100 2.1 1897:23 fp-um-17 2044 root 20 0 12.1g 668m 124m R 100 2.1 1897:23 fp-um-19 2046 root 20 0 12.1g 668m 124m R 100 2.1 1897:23 fp-um-21 2047 root 20 0 12.1g 668m 124m R 100 2.1 1897:23 fp-um-22 2048 root 20 0 12.1g 668m 124m R 100 2.1 1897:23 fp-um-23 2049 root 20 0 12.1g 668m 124m R 100 2.1 1897:23 fp-um-24 2050 root 20 0 12.1g 668m 124m R 100 2.1 1897:22 fp-um-25 2051 root 20 0 12.1g 668m 124m R 100 2.1 1897:23 fp-um-26 1419 root 20 0 116m 5732 2280 S 0 0.0 0:02.00 chmgrd 1323 root 20 0 753m 70m 3764 S 0 0.2 1:51.20 confd 1432 root 20 0 1683m 172m 134m S 0 0.5 0:58.91 fpmd
Aquí, el promedio de carga siempre es alto porque 26 de los 28 procesadores funcionan al 100% debido al proceso fp-um.
Conclusión
El uso informado de la CPU en vManage para las versiones 17.2.x anteriores a 17.2.7 no es el uso real de la CPU, sino que se calcula en función del promedio de carga. Esto puede llevar a confusión a la hora de comprender el valor informado y conducir a falsas alarmas relacionadas con el uso elevado de la CPU mientras la plataforma funciona normalmente con tráfico normal, bajo o sin carga real de la red.
Este comportamiento se cambia/modifica con las versiones 17.2.7 y 18.2, de modo que la lectura de la CPU ahora puede ser precisa en base a la lectura cpu_user de arriba.
El problema también se menciona en las notas de la versión 17.2.
ComentariosContacte a Cisco
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)