Introdução
Este documento descreve a coleta de dados do Network Services Orchestrator (NSO) necessária quando o consumo de CPU aumenta para 100-150%.
Pré-requisitos
Requisitos
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.
As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. 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:
- Capturar as próximas informações a cada 'n' segundos (pode ser executado 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:
- 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-a 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.
Informações adicionais
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
Feedback