Raccogliere dati quando NSO utilizza CPU elevata

Introduzione

Questo documento descrive la raccolta dei dati NSO (Network Services Orchestrator) necessaria quando il consumo di CPU aumenta fino al 100-150%.

Prerequisiti

Requisiti

Nessun requisito specifico previsto per questo documento.

Componenti usati

Il documento può essere consultato per tutte le versioni software o hardware.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Premesse

Quando vengono elaborate più transazioni da NB, l'utilizzo della CPU NSO aumenta fino a circa il 100-150% del consumo normale. In questo caso, è necessario individuare la causa del downgrade delle prestazioni della CPU. Inoltre, l'NSO non risponde correttamente alle query RESTCONF (se utilizzate).

In questo articolo vengono evidenziati tutti i dati importanti che è necessario raccogliere durante il problema, in modo che il problema possa essere risolto correttamente e vengono suggerite alcune soluzioni.

Dati da raccogliere

Dal punto di vista di Linux:

• lscpu
• in alto
• free -h
• vmstat
• cat/proc/meminfo
• pstree -c
• ps auxw | ordinare

Nota: è possibile acquisire questi dettagli (ad eccezione di 'lscpu') a intervalli regolari per comprendere il comportamento del sistema quando le richieste provengono da NB.

Dal punto di vista dell'NSO:

• ncs —status | blocco grep
• Abilitare la traccia di avanzamento:

  admin@ncs(config)# commit dry-run 

  cli{

      nodo locale {

          stato dei dati {

               + traccia tutto {

               + destinazione {

               + file progress-all.txt;

               + formato log;

               + }

               + }

                }

      }

  }

  admin@ncs(config)# commit

• Acquisisci le informazioni successive ogni 'n' secondi (può essere eseguito come script):

seq=0
while ncs —status >& /dev/null; do
ncs —debug-dump ncs.dd.$(seq++));
ncs —status > ncs.stat.$(seq++);
sleep 30; #Configurato according  all'utente
fine

Di seguito sono riportate alcune azioni correttive che possono essere eseguite anche per ridurre il problema:

1. Limitare il numero di sessioni come segue (attualmente non si dispone di questo set):

<limiti sessione>

  <limite sessione>

    <context>rest</context>

    <max-session>100</max-session>

  </session-limit>

</session-limit>

b. Abilitare la regola di controllo per verificare se il processo NSO è stato interrotto da un evento e, in caso affermativo, registrarlo nel file audit.log:

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

Per la risoluzione dei problemi e l'analisi, sono necessari i dettagli precedenti insieme a audit.log, devel.log (preferibilmente impostato su level=trace), ncs-java-vm.log e i registri NB.

Ulteriori informazioni

D. In che modo NSO gestisce effettivamente le richieste RESTCONF da un'applicazione NB?

R. Quando un'applicazione in direzione nord invia una richiesta RESTCONF, viene considerata come una transazione univoca basata su NSO. Ciò significa che l'NSO può bloccare l'intero CDB e non consentire altre transazioni fino al completamento della transazione corrente.In tal caso, la natura transazionale dell'NSO viene mantenuta e garantisce che sia possibile eseguire un rollback in caso di problemi.

La coda di commit NSO può elaborare ogni richiesta di transazione successiva al completamento ed è possibile tenere traccia del blocco della transazione nel file devel.log al momento dell'avvio o del completamento. Nei casi di utilizzo in cui viene eseguita una grande quantità di query, viene introdotto un notevole sovraccarico in NSO e le transazioni restano nella coda di commit più a lungo del previsto. Se le richieste RESTCONF fossero raggruppate, il throughput aumenterebbe, in quanto il sovraccarico della transazione diminuirebbe. Inoltre, NSO sarebbe in grado di fare il possibile contemporaneamente, nell'ambito di una singola transazione. Ad esempio, se una transazione contiene 2 modifiche alla configurazione del dispositivo, l'NSO può bloccare il CDB, raggiungere e modificare entrambi i dispositivi contemporaneamente, quindi completare la transazione. Ciò è in contrasto con 2 transazioni che contengono ciascuna 1 dispositivo ed entrambe sono modificate; poiché l'NSO può bloccare il CDB per la prima transazione, modificare il primo dispositivo, completare la transazione, quindi eseguire gli stessi passaggi per il secondo dispositivo.

Informazioni correlate