Fehlerbehebung bei Problemen mit hoher Speicherauslastung mit CPS

Einleitung

In diesem Dokument wird das Verfahren zur Fehlerbehebung bei Problemen mit der hohen Speichernutzung bei der Cisco Policy Suite (CPS) beschrieben.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

• Linux 
• CPS
• MongoDB

Verwendete Komponenten

Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:

• CPS 20.2
• Unified Computing System (UCS)-B
• MongoDB v3.6.17

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

Linux bietet eine breite Palette von Tools zur Unterstützung, Verwaltung, Überwachung und Bereitstellung von Softwareanwendungen.

Services und Funktionen, die der Produktanwendung hinzugefügt werden, können beträchtlichen Arbeitsspeicher belegen. Die Speicheroptimierung für Linux-Server sorgt nicht nur für einen reibungsloseren und schnelleren Betrieb der Anwendungen, sondern reduziert auch das Risiko von Datenverlusten und Serverabstürzen.

Um den Speicher für Linux-Maschinen zu optimieren, müssen Sie zunächst verstehen, wie der Speicher unter Linux funktioniert. Sie beginnen mit einigen Speicherbegriffen, besprechen, wie Linux mit Speicher umgeht, und lernen dann, wie Sie Speicherprobleme beheben und vermeiden.

Der gesamte Speicher, den ein System enthalten kann, basiert auf der Architektur des Betriebssystems.

Der gesamte Speicher in Linux wird als virtueller Speicher bezeichnet - er umfasst physischen Speicher (oft als RAM bezeichnet - Randon Access Memory) und Auslagerungsspeicher. Der physische Speicher eines Systems kann nur erhöht werden, wenn Sie mehr RAM hinzufügen. Der virtuelle Speicher kann jedoch durch die Verwendung von Auslagerungsspeicher von der Festplatte erhöht werden.

Der RAM bestimmt, ob Ihr Computer Prozesse mit hohem Speicherverbrauch verarbeiten kann.

Daten vom Benutzer, Computerprozessen und von der Festplatte (Hard Disk Drive, HDD) werden an den RAM gesendet. Bei Bedarf speichert der RAM die Daten und sendet sie zurück an den Benutzer oder an die Festplatte. Wenn die Daten persistent sein müssen, werden sie vom RAM an die CPU (Central Processing Unit) gesendet.

Um den verfügbaren freien Speicherplatz auf Ihrem Computer zu überprüfen, können Sie den Befehl free verwenden.

[root@installer ~]# free -h
total used free shared buff/cache available
Mem: 11Gi 1.3Gi 2.9Gi 105Mi 7.4Gi 10Gi
Swap: 0B 0B 0B
[root@installer ~]#

Problem

Ein Linux-Server kann aus verschiedenen Gründen eine beträchtliche Speichermenge verbrauchen. Für eine effektive und schnelle Fehlerbehebung müssen Sie zunächst die wahrscheinlichsten Gründe ausschließen.

Java-Prozess:

Es gibt mehrere Anwendungen, die durch die Verwendung von Java implementiert werden, und ihre falsche Implementierung oder Konfiguration kann zu einer hohen Speichernutzung im Server führen. Die zwei häufigsten Ursachen sind falsche Konfigurationen im Caching und Session Caching Anti-Pattern.

Caching ist eine gängige Methode, um eine hohe Leistung für Anwendungen zu erzielen, aber wenn es falsch angewendet wird, kann es stattdessen zu einer Beeinträchtigung der Systemleistung führen. Die falsche Konfiguration kann dazu führen, dass der Cache zu schnell wächst und weniger Speicher für andere Prozesse im System verbleibt.

Die Zwischenspeicherung von Sitzungen wird häufig verwendet, wenn der Zwischenzustand der Anwendung gespeichert wird. Es ermöglicht Entwicklern, Benutzer pro Sitzung zu speichern und macht es einfach, Datenobjektwert zu speichern oder abzurufen. Allerdings vergessen Entwickler tendenziell, später Session-Caching-Daten zu bereinigen.

Beim Arbeiten mit Datenbanken in Java wird normalerweise eine Ruhesitzung verwendet, um Verbindungen herzustellen und die Sitzung zwischen dem Server und der Datenbank zu verwalten. Es gibt jedoch einen Fehler, der häufig auftritt, wenn Entwickler mit Ruhezustandssitzungen arbeiten. Statt aus Sicherheitsgründen für den Thread isoliert zu werden, ist die Ruhesitzung Teil derselben HTTP-Sitzung (Hypertext Transfer Protocol). Dadurch wird das Speichern von Zuständen in der Anwendung unnötig, und mit nur wenigen Benutzern nimmt die Speichernutzung stark zu.

Datenbank:

Wenn Sie von Prozessen mit hohem Speicherverbrauch sprechen, müssen Sie Datenbanken erwähnen. Mit vielen Lese- und Schreibvorgängen in die Datenbank, während die Anwendung Benutzeranfragen verarbeitet, kann unsere Datenbank erheblichen Arbeitsspeicher belegen.

Nehmen wir eine MongoDB-Datenbank als Referenz: Um eine hohe Leistung zu erreichen, wendet sie einen Puffermechanismus für das Caching und die Indizierung von Daten an. Wenn Sie die Datenbank so konfigurieren, dass sie bei mehreren Anforderungen an die Datenbank den maximalen Arbeitsspeicher verwendet, kann der Arbeitsspeicher Ihres Linux-Servers bald überlastet sein.

Der CPS-Speicherverbrauch kann mithilfe geeigneter KPIs in Grafana-Diagrammen oder anderen Überwachungstools überwacht werden. Wenn der Speicherverbrauch auf einem virtuellen CPS-System über den Standardschwellenwert von 90 % ansteigt, kann CPS einen Alarm bei niedrigem Speicher für dieses virtuelle System generieren. Dieser Schwellenwert kann mithilfe der free_mem_per-Einstellungen in der CPS-Bereitstellungsvorlage konfiguriert werden.

Identifizieren Sie den Prozess bzw. das Dienstprogramm, der bzw. das eine hohe Speicherauslastung verursacht:

1. Melden Sie sich bei dem virtuellen System an, das einen Alarm bei niedrigem Speicher ausgelöst hat.

2. Navigieren Sie zum /var/log Verzeichnis, und checken Sie die top_memory_consuming_processesDatei ein, um die Prozess-ID (PID) mit einem hohen prozentualen Speicherverbrauch zu identifizieren.

 ******************** Date: Tue May 16 05:06:01 UTC 2023 ***************** 
PID PPID CMD %MEM %CPU RSS PRI STAT PSR WCHAN NI P
9435 1 /usr/bin/java -XX:OnOutOfMe 26.7 77.9 4353796 5 S<l 2 - -15 *
24139 1 /usr/java/default/bin/java 1.0 0.0 174636 20 Sl 3 - 0 *
2905 2862 /usr/sbin/collectd -C /etc/ 1.0 0.2 169104 20 Sl 1 hrtimer_nanosl 0 *
913 1 /usr/lib/systemd/systemd-jo 0.4 0.1 69364 20 Ss 5 do_epoll_wait 0 *
1513 1 /usr/libexec/platform-pytho 0.1 0.0 27912 20 Ssl 5 - 0 *
3379 2905 /usr/sbin/collectd -C /etc/ 0.1 0.0 23716 20 Sl 3 - 0 *
3377 2905 /usr/sbin/collectd -C /etc/ 0.1 0.0 23712 20 Sl 4 - 0 *
3378 2905 /usr/sbin/collectd -C /etc/ 0.1 0.0 23712 20 Sl 5 - 0 *
3380 2905 /usr/sbin/collectd -C /etc/ 0.1 0.0 23712 20 Sl 5 - 0 *
******************** END *****************

3. Validieren Sie den Prozess mit diesem Befehl, unabhängig davon, ob es sich um einen Anwendungs- oder Datenbankprozess handelt.

#ps -ef | grep <PID>

Verfahren zur Behebung von Problemen mit der hohen Speichernutzung bei CPS

Die Optimierung des Speichers unter Linux ist komplex, und das Reparieren eines überlasteten Speichers erfordert erheblichen Aufwand.

Ansatz 1.


Erkennen und Wiederherstellen von Cache-Speicher:

In einigen Fällen kann ein Alarm bei niedrigem Speicher das Ergebnis einer Linux-Speicherverwaltung sein, die Objekte im Cache zuordnet.

Auswerten, wie viel Speicher eine VM zwischengespeichert hat, und Auslösen von Linux, um einen Teil des zwischengespeicherten Speichers freizugeben.

1. Vergleichen Sie den zwischengespeicherten Arbeitsspeicher von zwei oder mehr CPS-VMs, und führen Sie dazu den free -m Befehl auf jeder VM aus.

[root@dc1-qns01 ~]# free -m
total used free shared buff/cache available
Mem: 15876 5262 4396 808 6217 9628
Swap: 4095 0 4095
[root@dc1-qns01 ~]#

2. Führen Sie diesen Befehl aus, um einen Teil des inaktiven zwischengespeicherten Speichers wieder zu verwenden.

#free && sync && echo 3 > /proc/sys/vm/drop_caches && echo "" && free

[root@dc1-qns01 ~]# free -m
total used free shared buff/cache available
Mem: 15876 5016 8782 872 2076 9809
Swap: 4095 0 4095
[root@dc1-qns01 ~]#

Bitte beachten:
1. Dieser Befehl verwirft Cache-Objekte, die eine vorübergehende Erhöhung der E/A-Auslastung (Input Output) und der CPU-Auslastung (Central Processing Unit) verursachen können. Es wird daher empfohlen, diesen Befehl außerhalb der Spitzenzeiten auszuführen.
2. Dies ist ein zerstörungsfreier Befehl und nur freier Speicher, der nicht verwendet wird.

Wenn der Alarm bei niedrigem Speicher weiterhin nicht behoben wird, fahren Sie mit Ansatz 2 fort.

Ansatz 2.

Wenn der hohe Speicherverbrauch auf einen der Anwendungsprozesse wie QNS usw. zurückzuführen ist.

 1. Starten Sie den Prozess neu.

Command Syntax:

#monit restart <process name>

 2. Überprüfen Sie die Reduzierung der Speichernutzung durch free-m Befehl.

Wenn der Alarm bei niedrigem Speicher weiterhin nicht behoben wird, fahren Sie mit Ansatz 3 fort.

Ansatz 3:

Starten Sie das virtuelle System, für das Alarme generiert wurden, neu, da ein Neustart des virtuellen Systems normalerweise durchgeführt wird, um die Ressourcen für das virtuelle System zu erhöhen (Festplattenspeicher-CPU).

Wenn eine hohe Speichernutzung für sessionmgr VM festgestellt wurde, fahren Sie mit Ansatz 4 fort.

Ansatz 4:

1. Melden Sie sich bei der VM an, bei der eine hohe Speicherauslastung festgestellt wurde.

2. Navigieren Sie zum /var/log Verzeichnis, und checken Sie die Datei einmongodb-<xxxx>.log, um Warnungen/Meldungen bezüglich der Speicherbelegung und der Parameter zu erhaltenwriteConcernMajorityJournalDefault.

2022-12-13T00:30:39.012+0200 I REPL [replexec-0] ** WARNING: This replica set node is running without journaling enabled but the
2022-12-13T00:30:39.012+0200 I REPL [replexec-0] ** writeConcernMajorityJournalDefault option to the replica set config
2022-12-13T00:30:39.012+0200 I REPL [replexec-0] ** is set to true. The writeConcernMajorityJournalDefault
2022-12-13T00:30:39.012+0200 I REPL [replexec-0] ** option to the replica set config must be set to false
2022-12-13T00:30:39.012+0200 I REPL [replexec-0] ** or w:majority write concerns will never complete.
2022-12-13T00:30:39.012+0200 I REPL [replexec-0] ** In addition, this node's memory consumption may increase until all
2022-12-13T00:30:39.012+0200 I REPL [replexec-0] ** available free RAM is exhausted.

3. Melden Sie sich bei der jeweiligen mongoShell an und überprüfen Sie die aktuellen Werte von mongo protocolVersion und writeConcernMajorityJournalDefault .

set04:PRIMARY> rs.status().optimes.lastCommittedOpTime.t
NumberLong(0)
set04:PRIMARY>

set04:PRIMARY> rs.conf().writeConcernMajorityJournalDefault
set04:PRIMARY>

Hinweis: Wenn die Ausgabe keine zurückgibt, müssen Sie berücksichtigen, dass derwriteConcernMajorityJournalDefault Wert standardmäßig auf true festgelegt ist.

4. Wenn protocolVersion is 1 und writeConcernMajorityJournalDefault value true ist, führen Sie diese Befehle von der jeweiligen mongoShell aus, um value zu ändernwriteConcernMajorityJournalDefault in  false.

#cfg=rs.conf()
#cfg.writeConcernMajorityJournalDefault=false
#rs.reconfig(cfg)

5. Überprüfen Sie, ob sich derwriteConcernMajorityJournalDefault Wert in geändert hatfalse.

set03:PRIMARY> rs.conf().writeConcernMajorityJournalDefault
false
set03:PRIMARY>

6. Überprüfen Sie die Reduzierung der Speichernutzung durch free-m Befehl.