Compreender a alta utilização de CPU relatada pelo vManage para plataformas de nuvem vEdge 5000/2000/1000/100B e vEdge
Contents
Introdução
Este documento descreve por que você pode ver o alto uso de CPU relatado no vManage para plataformas vEdge 5000/2000/1000/100B e vEdge Cloud, apesar do desempenho das plataformas ser normal, sem alta CPU relatada como vista no topo.
Compreender a alta utilização de CPU relatada nas plataformas de nuvem vEdge 5000/2000/1000/100B e vEdge
Com as versões 17.2.x e posteriores, é possível observar maior consumo de CPU e memória para as plataformas vEdge e vEdge Cloud. Isso é observado no Painel do vManage para um determinado dispositivo. Em alguns casos, isso também leva a um número maior de alertas e avisos no vManage.
Explicação
O motivo para o alto uso de CPU relatado quando o dispositivo funciona normalmente com carga normal, baixa ou sem carga é devido a uma alteração na fórmula usada para calcular o uso. Com as versões 17.2, a utilização da CPU é calculada com base na Média de Carga de show system status no vEdge.
O vManage mostra a utilização da CPU em tempo real para um dispositivo. Ele obtém a média de 1 minuto [min1_avg] e a média de 5 minutos [min5_avg] com base em dados históricos. Carga Média, por definição, inclui vários itens e não apenas ciclos de CPU que contribuem para o cálculo de utilização. Por exemplo, o tempo de espera de E/S, o tempo pendente do processo e outros valores são considerados quando você apresenta esse valor para a plataforma. Nesse caso, ignore os valores mostrados para os estados da CPU e os valores da CPU no comando top do vShell.
Aqui está um exemplo de como a utilização da CPU, que na verdade é a média de carga de 1 minuto, é calculada e mostrada no painel do vManage:
Quando você verifica o carregamento de uma CLI do vEdge, isso pode ser visto:
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
Nesse caso, a utilização da CPU é calculada com base em Load-Average / # of Cores (vCPUs). Para este exemplo, o nó tem 4 núcleos. A média de carga é então convertida por um fator de 100 antes que você divida pelo número de núcleos. Quando você faz a média da carga de todos os núcleos e multiplica por 100, você chega a um valor de ~310. Pegue esse valor e divida por 4 rendimentos, uma leitura de CPU de 77,5%, que se alinha com o valor visto no gráfico em tempo real no vManage capturado no momento em que a saída CLI foi coletada e como mostrado na imagem.
Para ver as médias de carga e o número de núcleos de CPU no sistema, a saída de top pode ser consultada do vShell no dispositivo.
No exemplo aqui, o vEdge contém 4 vCPUs. O primeiro núcleo (Cpu0) é usado para Control (visto através da menor utilização do usuário) enquanto os 3 núcleos restantes são usados 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 obter o número de CPUs da CLI do vEdge, este comando pode ser usado:
vEdge# show system status | display xml | include total_cpu
<total_cpu_count>4</total_cpu_count>
Outro exemplo de cálculo para o valor mostrado no vManage no vEdge 1000 é fornecido aqui. Depois que você emite top do vShell, l está interessado em exibir a carga para todos os núcleos:
top - 18:19:49 up 19 days, 1:37, 1 user, load average: 0.55, 0.71, 0.73
Como um vEdge 1000 tem apenas um núcleo de CPU disponível, a carga relatada aqui é de 55% (0,55*100).
Alto uso da CPU com o processo fp-um
Às vezes, você também pode observar de cima que o processo fp-um é executado em alta e mostra até 100% de CPU. Isso é esperado nos núcleos da CPU que são usados para o processamento do plano de dados.
A partir do comando top mencionado anteriormente, 3 núcleos operam a 100% da CPU e 1 núcleo mostra utilização 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 ...
Esse primeiro núcleo (Cpu0) é usado para Controle e os três núcleos restantes são usados para Dados. Como você pode ver na lista de processos, o processo fp-um usa esses recursos.
fp-um é um processo que usa um driver de modo de pesquisa, o que significa que ele se ajusta e pesquisa constantemente a porta subjacente para pacotes, de modo que possa processar qualquer quadro assim que ele é recebido. Esse processo trata do encaminhamento e é equivalente ao encaminhamento rápido de caminho no vEdge 1000, vEdge 2000 e vEdge 100. Essa arquitetura de modo de pesquisa é usada pela Intel para o processamento eficiente de pacotes com base na estrutura do Data Plane Development Kit (DPDK). Como o encaminhamento de pacotes é implementado em um loop apertado, a CPU permanece em ou perto de 100% o tempo todo. Embora isso seja feito, nenhuma latência é introduzida através dessas CPUs, pois esse é o comportamento esperado.
Informações básicas sobre a pesquisa do DPDK podem ser encontradas aqui.
As plataformas vEdge Cloud e vEdge 5000 usam a mesma arquitetura de encaminhamento e apresentam o mesmo comportamento a esse respeito. Aqui está um exemplo de um vEdge 5000 extraído da saída de cima. Ele tem 28 núcleos, dos quais 2 (Cpu0 e Cpu1) são usados para controle (como o vEdge 2000) e 26 são usados para dados.
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
Aqui, a Carga Média é sempre alta porque 26 dos 28 processadores são executados a 100% devido ao processo fp-um.
Conclusão
O uso de CPU relatado no vManage para versões 17.2.x anteriores a 17.2.7 não é o uso real de CPU, mas é calculado com base na Média de carga. Isso pode levar a confusão na compreensão do valor relatado e levar a alarmes falsos relacionados à alta utilização da CPU, enquanto a plataforma opera normalmente com tráfego normal, baixo ou sem carga real de tráfego/rede.
Esse comportamento é alterado/modificado com as versões 17.2.7 e 18.2, de modo que a leitura da CPU agora possa ser precisa com base na leitura de cpu_user de cima.
O problema também é mencionado nas notas de versão 17.2.
FeedbackContate a Cisco
- Abrir um caso de suporte
- (É necessário um Contrato de Serviço da Cisco)