Recopilación de datos cuando NSO consume una gran cantidad de CPU

Introducción

Este documento describe la recopilación de datos de Network Services Orchestrator (NSO) necesaria cuando el consumo de CPU aumenta al 100-150%.

Prerequisites

Requirements

No hay requisitos específicos para este documento.

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Antecedentes

Cuando se procesan varias transacciones desde NB, el consumo de CPU de NSO aumenta hasta aproximadamente el 100-150% del consumo normal. Cuando esto sucede, debe encontrar la causa que reduce el rendimiento de la CPU. Y, al mismo tiempo, NSO no responde correctamente a las consultas RESTCONF (si se utiliza).

En este artículo se destacan todos los datos importantes que deben recopilarse durante el problema para poder solucionarlo correctamente y también se sugieren algunos pasos para solucionarlo.

Datos que deben recopilarse

Desde la perspectiva de Linux:

• lscpu
• arriba
• free -h
• vmstat
• cat /proc/meminfo
• pstree -c
• ps auxw | clasificar

Nota: Puede capturar estos detalles (excepto 'lscpu') a intervalos regulares para comprender cómo se comporta el sistema cuando las solicitudes provienen de NB.

Desde la perspectiva de NSO:

• ncs —status | grep lock
• Habilite el seguimiento de progreso:

  admin@ncs(config)# commit dry-run 

  cli{

      local-node {

          progreso de datos {

               + trace all {

               + destino {

               + file progress-all.txt;

               + registro de formato;

               + }

               + }

                }

      }

  }

  admin@ncs(config)# commit

• Capture la siguiente información cada 'n' segundos (se puede ejecutar como un script):

seq=0
mientras que ncs —status >& /dev/null; do
ncs —debug-dump ncs.dd.$((seq++));
ncs —status > ncs.stat.$((seq++));
sleep 30; #Configured according  al usuario
Fin

A continuación, se detallan algunos pasos de solución que también se pueden realizar para mitigar el problema:

1. Limite el número de sesiones de la siguiente manera (actualmente no tiene este conjunto):

<session-limits>

  <session-limit>

    <context>rest</context>

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

  </session-limit>

</session-limits>

b. Active la regla de auditoría para comprobar si el proceso NSO se ha visto afectado por algo y, en caso afirmativo, regístrelo en audit.log:

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

Para solucionar problemas y analizar, necesita los detalles anteriores junto con audit.log, devel.log (preferiblemente configurado en level=trace), ncs-java-vm.log y los registros NB.

Additional Information

P. ¿Cómo gestiona NSO las solicitudes RESTCONF de una aplicación NB?

R. Cuando una aplicación ascendente envía una solicitud RESTCONF, se trata como una transacción única basada en NSO. Esto significa que NSO puede bloquear todo el CDB y no permitir ninguna otra transacción hasta que se complete la transacción actual. Si esto se hace, se conserva la naturaleza transaccional de NSO y se garantiza que se puede realizar una reversión en caso de problemas.

La cola de confirmación de NSO puede procesar cada solicitud de transacción subsiguiente a medida que se completa, y puede realizar un seguimiento del bloqueo de transacción en el archivo devel.log a medida que se inicia o finaliza. En los casos prácticos en los que se realiza una gran cantidad de consultas, esto introduce una gran cantidad de sobrecarga en NSO; y las transacciones permanecen en la cola de confirmación durante más tiempo del esperado. En caso de que las solicitudes RESTCONF se agruparan, el rendimiento aumentaría, ya que se reduciría la sobrecarga de la transacción. Además, NSO podría hacer todo lo que pudiera al mismo tiempo, dentro de una única transacción. Por ejemplo, si una transacción contiene 2 cambios de configuración de dispositivos, NSO puede bloquear la CDB, acceder a ambos dispositivos y editarlos al mismo tiempo, y luego completar la transacción. Esto contrasta con 2 transacciones que cada una contiene 1 dispositivo y ambas se modifican; ya que NSO puede bloquear la CDB para la primera transacción, editar el primer dispositivo, completar la transacción y, a continuación, realizar los mismos pasos para el segundo dispositivo.

Información Relacionada