Erfassen von Daten bei hohem CPU-Bedarf des NSO

Einleitung

In diesem Dokument wird die Erfassung von Daten durch den Network Services Orchestrator (NSO) beschrieben, die erforderlich sind, wenn die CPU-Auslastung auf 100-150 % steigt.

Voraussetzungen

Anforderungen

Es gibt keine spezifischen Anforderungen für dieses Dokument.

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Hintergrundinformationen

Wenn mehrere Transaktionen von NB verarbeitet werden, steigt der CPU-Verbrauch des NSO auf ca. 100-150 % des Normalverbrauchs. In diesem Fall müssen Sie die Ursache finden, die die CPU-Leistung herabstuft. Gleichzeitig antwortet der NSO nicht korrekt auf RESTCONF-Abfragen (falls verwendet).

Dieser Artikel hebt alle wichtigen Daten hervor, die während des Problems gesammelt werden müssen, damit das Problem ordnungsgemäß behoben werden kann, und schlägt einige Abhilfemaßnahmen vor.

Zu erhebende Daten

Aus Linux-Perspektive:

• LSCPU
• oberste
• frei -h
• vmstat
• cat/proc/meminfo
• pstree -c
• ps auxw | Sorte

Hinweis: Sie können diese Details (mit Ausnahme von "lscpu") in regelmäßigen Abständen erfassen, um zu verstehen, wie sich das System verhält, wenn die Anfragen von NB kommen.

Aus Sicht des NSO:

• NCS - Status | Greifschloss
• Fortschrittsverfolgung aktivieren:

  admin@ncs(config)# commit-Testlauf 

  cli{

      Lokaler Knoten {

          Datenfortschritt {

               + trace all {

               + Ziel {

               + file progress-all.txt;

               + Format log;

               + }

               + }

                }

      }

  }

  admin@ncs(config)# commit

• Erfassen Sie die nächsten Informationen alle n Sekunden (sie können als Skript ausgeführt werden):

seq=0
while ncs —status >& /dev/null; do
ncs —debug-dump ncs.dd.$(seq++);
ncs —status > ncs.stat.$(seq++);
schlafen 30; #Configured according  an Benutzer
fertig

Die folgenden Abhilfemaßnahmen können ebenfalls durchgeführt werden, um das Problem zu beheben:

1. Begrenzen Sie die Anzahl der Sitzungen wie folgt (derzeit verfügen Sie nicht über diesen Satz):

<Sitzungslimits>

  <Sitzungslimit>

    <context>Rest</context>

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

  </session-limit>

</session-limits>

b. Aktivieren Sie die Überwachungsregel, um festzustellen, ob der NSO-Prozess durch einen Angriff beendet wurde, und notieren Sie ihn gegebenenfalls in audit.log:

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

Zur Fehlerbehebung und Analyse benötigen Sie die vorherigen Details zusammen mit den Protokollen audit.log, devel.log (vorzugsweise auf level=trace gesetzt), ncs-java-vm.log und NB.

Zusätzliche Informationen

Frage: Wie verarbeitet der NSO RESTCONF-Anfragen von einer NB-Anwendung?

A. Wenn eine Northbound-Anwendung eine RESTCONF-Anforderung sendet, wird sie als eindeutige Transaktion basierend auf dem NSO behandelt. Dies bedeutet, dass der NSO den gesamten CDB sperren kann und keine anderen Transaktionen zulässt, bis die aktuelle Transaktion abgeschlossen ist.In diesem Fall wird der transaktionale Charakter des NSO beibehalten, und es wird sichergestellt, dass bei Problemen ein Rollback durchgeführt werden kann.

Die Commit-Warteschlange des NSO kann jede nachfolgende Transaktionsanforderung nach Abschluss verarbeiten, und Sie können die Transaktionssperre in der Datei devel.log beim Start/Abschluss nachverfolgen. In Anwendungsfällen, in denen eine große Anzahl von Abfragen ausgeführt wird, führt dies zu einem großen Overhead im NSO, und Transaktionen befinden sich länger als erwartet in der Commit-Warteschlange. Bei einer Gruppierung der RESTCONF-Anforderungen würde sich der Durchsatz erhöhen, da der Transaktionsaufwand verringert würde. Außerdem kann der NSO innerhalb einer Transaktion so viele Funktionen wie möglich gleichzeitig nutzen. Wenn eine Transaktion z. B. zwei Gerätekonfigurationsänderungen enthält, kann der NSO den CDB sperren, beide Geräte gleichzeitig erreichen und bearbeiten und die Transaktion abschließen. Dies steht im Gegensatz zu zwei Transaktionen, die jeweils ein Gerät enthalten und beide geändert werden. Da der NSO den CDB für die erste Transaktion sperren kann, kann er das erste Gerät bearbeiten, die Transaktion abschließen und dann die gleichen Schritte für das zweite Gerät ausführen.

Zugehörige Informationen