Comprensión del uso elevado de la CPU según vManage para las plataformas de nube vEdge 5000/2000/1000/100B y vEdge
Contenido
Introducción
Este documento describe por qué puede aparecer un uso elevado de la CPU en vManage para las plataformas vEdge 5000/2000/1000/100B y vEdge Cloud, a pesar de que el rendimiento de las plataformas sea normal y de que no se informe de un uso elevado de la CPU como se ve en la parte superior.
Comprender el uso elevado de la CPU registrado 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 CPU y memoria para las plataformas vEdge y vEdge Cloud. Esto se advierte en el vManage Dashboard para un dispositivo determinado. En algunos casos, esto también conlleva un aumento del número de alertas y advertencias en vManage.
Explicación
El motivo del uso elevado de la CPU notificado cuando el dispositivo funciona normalmente con carga normal, baja o nula se debe a un cambio en la fórmula utilizada para calcular el uso. Con las versiones 17.2, el uso de la CPU se calcula en función del promedio de carga de show system status en vEdge.
vManage muestra el uso de la CPU en tiempo real de un dispositivo. Obtiene el Promedio de 1 minuto [min1_avg] y el Promedio de 5 minutos [min5_avg] basándose en los datos históricos. El promedio de carga, por definición, incluye varias cosas y no solo ciclos de CPU que contribuyen al cálculo de la utilización. Por ejemplo, el tiempo de espera de E/S, el tiempo pendiente de proceso y otros valores se tienen en cuenta al presentar este valor para la plataforma. En este caso, se ignoran los valores mostrados para los estados de CPU y los valores de CPU en el comando top de vShell.
A continuación se muestra un ejemplo de cómo se calcula el uso de la CPU, que es en realidad el promedio de carga de 1 minuto, y se muestra en el panel de vManage:
Al comprobar la carga desde una CLI de vEdge, se puede observar lo siguiente:
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. El promedio de carga se convierte por un factor de 100 antes de dividir por el número de núcleos. Cuando se calcula el promedio de carga de todos los núcleos y se multiplica por 100, se obtiene un valor de ~310. Tome este valor y divida por 4 rendimientos, una lectura de CPU del 77,5% de CPU, que se alinea con el valor visto en el gráfico en tiempo real de vManage capturado alrededor del momento en que se recopiló la salida 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 este ejemplo, 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 Data:
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 que se muestra 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 indicada aquí es del 55% (0,55*100).
Uso elevado de la CPU con el proceso fp-um
También puede notar a veces desde top que el proceso fp-um se ejecuta alto y muestra hasta 100% CPU. Esto se espera en los núcleos de CPU que se utilizan para el procesamiento del plano de datos.
Desde el comando top al que se hizo referencia anteriormente, 3 núcleos funcionan al 100% de la CPU y 1 núcleo muestra un uso 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 se utilizan para Data. 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 en busca de paquetes constantemente para que pueda procesar cualquier trama en cuanto se recibe. 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 de sondeo para el procesamiento eficaz de paquetes basado en el marco del kit de desarrollo de plano de datos (DPDK). Debido a que el reenvío de paquetes se implementa en un loop ajustado, la CPU permanece en o cerca del 100% en todo momento. Aunque esto se hace, no se introduce latencia a través de estas CPU, ya que se espera un comportamiento así.
Información de fondo sobre la encuesta DPDK puede encontrar aquí.
Las plataformas vEdge Cloud y vEdge 5000 utilizan la misma arquitectura de reenvío y muestran el mismo comportamiento en este sentido. 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 vEdge 2000) y 26 se utilizan para Data.
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 es siempre alto porque 26 de los 28 procesadores funcionan al 100% debido al proceso fp-um.
Conclusión
El uso de CPU notificado en vManage para las versiones 17.2.x anteriores a 17.2.7 no es el uso real de CPU, sino que se calcula en función del promedio de carga. Esto puede llevar a confusión en la comprensión del valor informado y llevar a falsas alarmas relacionadas con una CPU alta mientras la plataforma funciona normalmente con tráfico normal, bajo o sin carga real de red.
Este comportamiento se cambia/modifica con las versiones 17.2.7 y 18.2 de tal manera que la lectura de la CPU ahora puede ser precisa basada en la lectura de cpu_user de top.
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)