Contents

Introduction

Prerequisites

Requirements

Componentes Utilizados

Informações de Apoio

Dados a recolher

Additional Information

Informações Relacionadas

Introduction

Este documento descreve a coleta de dados do Network Services Orchestrator (NSO) necessária quando o consumo de CPU aumenta para 100-150%.

Prerequisites

Requirements

Não existem requisitos específicos para este documento.

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Informações de Apoio

Quando várias transações são processadas do NB, o consumo de CPU do NSO aumenta para aproximadamente 100-150% do consumo normal. Quando isso acontece, você precisa encontrar a causa que reduz o desempenho da CPU. Ao mesmo tempo, o NSO não responde corretamente às consultas RESTCONF (se usadas).

Este artigo destaca todos os dados importantes que precisam ser coletados durante o problema para que ele possa ser solucionado corretamente e também sugere algumas etapas de correção.

Dados a recolher

Da perspectiva do Linux:

- lscpu

- superior

- free -h

- vmstat

- cat /proc/meminfo

- pstree -c

- ps auxw | classificar

Observação: você pode capturar esses detalhes (exceto 'lscpu') em intervalos regulares para entender como o sistema se comporta quando as solicitações vêm do NB.

Do ponto de vista da NSO:

- ncs — status | bloqueio grep

- Habilitar o rastreamento do progresso:
admin@ncs(config)#commit dry-run

cli{

nó local {

progresso de dados {

+ trace all {

+ destino {

+ arquivo progress-all.txt;

+ format log;

+ }

+ }

}

}

}

admin@ncs(config)#commit

- Capturar as próximas informações a cada 'n' segundos (elas podem ser executadas como um script):

seq=0

enquanto ncs — status >& /dev/null; do

ncs —debug-dump ncs.dd.$((seq++));

ncs —status > ncs.stat.$((seq++));

sono 30; #Configured according  para o usuário

done

A seguir estão algumas etapas de correção que também podem ser executadas para mitigar o problema:

1. Limite o número de sessões da seguinte maneira (atualmente, você não tem esse conjunto):

<limites de sessão>

<session-limit>

<context>rest</context>

<max-sessions>100</max-sessions>

</session-limit>

</session-limits>

b. Ative a regra de auditoria para determinar se o processo NSO foi eliminado por alguma coisa e, se foi, registre-o em audit.log:

sudo auditctl -a exit,always -F arch=b64 -S kill -k audit_kill

Para solucionar problemas e analisar, você precisa dos detalhes anteriores junto com os logs audit.log, devel.log (preferencialmente definido em level=trace), ncs-java-vm.log e NB.

Additional Information

P. Como o NSO realmente trata as solicitações RESTCONF de um aplicativo NB?

R. Quando uma aplicação ascendente envia uma solicitação RESTCONF, ela é tratada como uma transação exclusiva com base em NSO. Isso significa que o NSO pode bloquear todo o CDB e não permitir nenhuma outra transação até que a transação atual seja concluída.Se isso for feito, a natureza transacional do NSO será preservada e garantirá que uma reversão possa ser feita em caso de qualquer problema.

A fila de confirmação NSO pode processar cada solicitação de transação subsequente à medida que for concluída e você pode rastrear o bloqueio de transação no devel.log à medida que eles forem iniciados/concluídos. Nos casos de uso em que uma grande quantidade de consultas é feita, isso introduz uma grande quantidade de sobrecarga no NSO e as transações ficam na fila de confirmação por mais tempo do que o esperado. Caso as solicitações RESTCONF fossem agrupadas, o throughput aumentaria, pois o overhead da transação seria reduzido. Além disso, a NSO seria capaz de fazer o máximo que puder ao mesmo tempo, dentro de uma única transação. Por exemplo, se uma transação contém 2 alterações de configuração de dispositivo, o NSO pode bloquear o CDB, alcançar e editar ambos os dispositivos ao mesmo tempo, em seguida, completar a transação Isso é em contraste com 2 transações que cada contém 1 dispositivo e ambos são alterados; como o NSO pode bloquear o CDB para a primeira transação, editar o primeiro dispositivo, completar a transação, em seguida, fazer os mesmos passos para o segundo dispositivo.

Informações Relacionadas

- Suporte técnico e downloads da Cisco