Eine neue Perspektive auf die Beobachtbarkeit des Containerspeichers: WorkingSet- und PageCache-Überwachung

Das Open-Source-Community-Team China machte seine erste Live-Übertragung und erzählte im Namen des Teilens die Geschichte hinter der Open-Source-Community China.“

Autor: Xingji, Changjun, Youyi, Liutao

Einführung in das Konzept des Container-Arbeitsspeichers WorkingSet

Im Kubernetes-Szenario werden Echtzeitstatistiken zur Containerspeichernutzung (Pod-Speicher) durch WorkingSet-Arbeitsspeicher (abgekürzt als WSS) dargestellt.

Das Indikatorkonzept von WorkingSet wird von cadvisor für Containerszenarien definiert.

Arbeitsspeicher WorkingSet ist auch ein Indikator für Kubernetes-Planungsentscheidungen zur Bestimmung von Speicherressourcen, einschließlich Knotenräumung.

WorkingSet-Berechnungsformel

Offizielle Definition: Weitere Informationen finden Sie in der offiziellen Website-Dokumentation von K8

https://kubernetes.io/docs/concepts/scheduling-eviction/node-pression-eviction/#eviction-signals

Die folgenden zwei Skripte können auf dem Knoten ausgeführt werden, um die Ergebnisse direkt zu berechnen:

CGroupV1

https://kubernetes.io/examples/admin/resource/memory-available.sh

#!/bin/bash
#!/usr/bin/env bash

# This script reproduces what the kubelet does
# to calculate memory.available relative to root cgroup.

# current memory usage
memory_capacity_in_kb=$(cat /proc/meminfo | grep MemTotal | awk '{print $2}')
memory_capacity_in_bytes=$((memory_capacity_in_kb * 1024))
memory_usage_in_bytes=$(cat /sys/fs/cgroup/memory/memory.usage_in_bytes)
memory_total_inactive_file=$(cat /sys/fs/cgroup/memory/memory.stat | grep total_inactive_file | awk '{print $2}')

memory_working_set=${memory_usage_in_bytes}
if [ "$memory_working_set" -lt "$memory_total_inactive_file" ];
then
    memory_working_set=0
else
    memory_working_set=$((memory_usage_in_bytes - memory_total_inactive_file))
fi

memory_available_in_bytes=$((memory_capacity_in_bytes - memory_working_set))
memory_available_in_kb=$((memory_available_in_bytes / 1024))
memory_available_in_mb=$((memory_available_in_kb / 1024))

echo "memory.capacity_in_bytes $memory_capacity_in_bytes"
echo "memory.usage_in_bytes $memory_usage_in_bytes"
echo "memory.total_inactive_file $memory_total_inactive_file"
echo "memory.working_set $memory_working_set"
echo "memory.available_in_bytes $memory_available_in_bytes"
echo "memory.available_in_kb $memory_available_in_kb"
echo "memory.available_in_mb $memory_available_in_mb"

CGroupV2

https://kubernetes.io/examples/admin/resource/memory-available-cgroupv2.sh

#!/bin/bash

# This script reproduces what the kubelet does
# to calculate memory.available relative to kubepods cgroup.

# current memory usage
memory_capacity_in_kb=$(cat /proc/meminfo | grep MemTotal | awk '{print $2}')
memory_capacity_in_bytes=$((memory_capacity_in_kb * 1024))
memory_usage_in_bytes=$(cat /sys/fs/cgroup/kubepods.slice/memory.current)
memory_total_inactive_file=$(cat /sys/fs/cgroup/kubepods.slice/memory.stat | grep inactive_file | awk '{print $2}')

memory_working_set=${memory_usage_in_bytes}
if [ "$memory_working_set" -lt "$memory_total_inactive_file" ];
then
    memory_working_set=0
else
    memory_working_set=$((memory_usage_in_bytes - memory_total_inactive_file))
fi

memory_available_in_bytes=$((memory_capacity_in_bytes - memory_working_set))
memory_available_in_kb=$((memory_available_in_bytes / 1024))
memory_available_in_mb=$((memory_available_in_kb / 1024))

echo "memory.capacity_in_bytes $memory_capacity_in_bytes"
echo "memory.usage_in_bytes $memory_usage_in_bytes"
echo "memory.total_inactive_file $memory_total_inactive_file"
echo "memory.working_set $memory_working_set"
echo "memory.available_in_bytes $memory_available_in_bytes"
echo "memory.available_in_kb $memory_available_in_kb"
echo "memory.available_in_mb $memory_available_in_mb"

Zeig mir den Code

Wie Sie sehen können, entspricht der Arbeitsspeicher des WorkingSets des Knotens der Speichernutzung der Root-Cgroup abzüglich des Caches des Inactve(file)-Teils. Ebenso ist der WorkingSet-Arbeitsspeicher des Containers im Pod die Cgroup-Speichernutzung, die dem Container entspricht, abzüglich des Caches des Inactve(file)-Teils.

Im Kubelet der echten Kubernetes-Laufzeit lautet der tatsächliche Code dieses Teils der von Cadvisor bereitgestellten Indikatorlogik wie folgt:

Aus dem Cadvisor-Code [ 1] können Sie die Definition des WorkingSet-Arbeitsspeichers deutlich erkennen:

The amount of working set memory, this includes recently accessed memory,dirty memory, and kernel memory. Working set is <= "usage".

Und die spezifische Code-Implementierung der Berechnung von WorkingSet durch Cadvisor [ 2] :

inactiveFileKeyName := "total_inactive_file"
if cgroups.IsCgroup2UnifiedMode() {
  inactiveFileKeyName = "inactive_file"
}
workingSet := ret.Memory.Usage
if v, ok := s.MemoryStats.Stats[inactiveFileKeyName]; ok {
  if workingSet < v {
    workingSet = 0
  } else {
    workingSet -= v
  }
}

Häufige Benutzerprobleme bei Containerspeicherproblemen

Während das ACK-Team einer großen Anzahl von Benutzern Serviceunterstützung für Containerszenarien bereitstellt, sind viele Kunden bei der Bereitstellung ihrer Geschäftsanwendungen in Containern mehr oder weniger auf Containerspeicherprobleme gestoßen. Nachdem eine große Anzahl von Kundenproblemen aufgetreten ist, haben das ACK-Team und das Alibaba Cloud-Betriebssystemteam die folgenden häufigen Probleme zusammengefasst, mit denen Benutzer in Bezug auf den Containerspeicher konfrontiert sind:

FAQ 1: Es besteht eine Lücke zwischen der Speichernutzung des Hosts und der aggregierten Nutzung des Containers nach Knoten. Der Host beträgt etwa 40 % und der Container etwa 90 %.

Höchstwahrscheinlich liegt es daran, dass der Pod des Containers als WorkingSet betrachtet wird, das Caches wie PageCache enthält.

Der Speicherwert des Hosts umfasst nicht Cache, PageCache, Dirty Memory usw., während der Arbeitsspeicher diesen Teil enthält.

Die häufigsten Szenarien sind die Containerisierung von JAVA-Anwendungen, Log4J von JAVA-Anwendungen und die sehr beliebte Implementierung von Logback. Der Standard-Appender verwendet NIO sehr „einfach“ und verwendet mmap, um Dirty Memory zu verwenden. Dies führt zu einer Vergrößerung des Speicher-Cache und damit zu einer Vergrößerung des Arbeitsspeicher-WorkingSets des Pods.

Logback-Protokollierungsszenario eines JAVA-Anwendungs-Pods

Instanzen, die eine Vergrößerung des Cache-Speichers und des WorkingSet-Speichers verursachen

FAQ 2: Beim Ausführen des Top-Befehls in einem Pod ist der erhaltene Wert kleiner als der vom kubectl Top-Pod angezeigte Arbeitsspeicherwert (WorkingSet).

Führen Sie den Top-Befehl im Pod aus. Aufgrund von Problemen wie der Container-Laufzeitisolation wird die Container-Isolation tatsächlich unterbrochen und der Top-Überwachungswert des Hosts erhalten.

Was Sie also sehen, ist der Speicherwert des Host-Computers, der Cache, PageCache, Dirty Memory usw. nicht umfasst, während der Arbeitsspeicher diesen Teil enthält, also ähnlich wie bei FAQ 1.

FAQ 3: Problem mit dem Schwarzen Loch im Pod-Speicher

图/Kernel-Level-Speicherverteilung

Wie in der Abbildung oben gezeigt, enthält der Arbeitsspeicher des Pod WorkingSet nicht Inactive (anno), und die anderen vom Benutzer verwendeten Komponenten des Pod-Speichers erfüllen nicht die Erwartungen, was schließlich zu einer Erhöhung der WorkingSet-Arbeitslast und schließlich zu Node führen kann Räumung.

Es ist blind wie ein schwarzes Loch, die wahre Ursache für den Anstieg des Arbeitsspeichers unter den vielen Speicherkomponenten zu finden. („Memory Black Hole“ bezieht sich auf dieses Problem).

So lösen Sie das WorkingSet-High-Problem

Normalerweise gehen Verzögerungen beim Speicherrecycling mit einer hohen Arbeitsspeicherauslastung einher. Wie lässt sich ein solches Problem lösen?

Direkte Erweiterung

Kapazitätsplanung (Direktausbau) ist eine allgemeine Lösung für das Problem hoher Ressourcen.

„Speicher-Schwarzes Loch“ – was tun, wenn es durch tiefe Speicherkosten verursacht wird (z. B. PageCache)

Wenn Sie jedoch Speicherprobleme diagnostizieren möchten, müssen Sie zunächst analysieren, Erkenntnisse gewinnen, analysieren oder, um es menschlich auszudrücken, klar erkennen, welcher Teil des Speichers von wem gehalten wird (welcher Prozess oder welche spezifische Ressource, z. B. eine Datei). Führen Sie dann eine gezielte Konvergenzoptimierung durch, um das Problem endgültig zu lösen.

Schritt eins: Überprüfen Sie den Speicher

Erstens: Wie analysiert man die Speicherindikatoren für die Containerüberwachung auf Kernelebene des Betriebssystems? Das ACK-Team hat mit dem Betriebssystemteam zusammengearbeitet, um die SysOM-Produktfunktion (System Observer Monitoring) zur Containerüberwachung auf der Kernelebene des Betriebssystems zu starten, die derzeit nur für Alibaba Cloud verfügbar ist, indem der Pod Memory Monitor im SysOM-Container angezeigt wird Systemüberwachung-Pod-Dimension : Sie können Einblick in die detaillierte Speichernutzungsverteilung des Pods erhalten, wie unten gezeigt:

Die SysOM-Containersystemüberwachung kann die detaillierte Speicherzusammensetzung jedes Pods auf granularer Ebene anzeigen. Durch die Überwachung und Anzeige verschiedener Speicherkomponenten wie Pod Cache (Cache-Speicher), InactiveFile (inaktive Dateispeichernutzung), InactiveAnon (inaktive anonyme Speichernutzung) und Dirty Memory (System-Dirty-Speichernutzung) treten häufig Black-Hole-Probleme im Pod-Speicher auf entdeckt.

Für den Pod-Datei-Cache können Sie die PageCache-Nutzung der aktuell geöffneten und geschlossenen Dateien des Pods gleichzeitig überwachen (durch das Löschen der entsprechenden Dateien kann der entsprechende Cache-Speicher freigegeben werden).

Schritt 2: Speicher optimieren

Es gibt viele tiefgreifende Speicherbelegungen, die Benutzer nicht einfach konvergieren können, selbst wenn sie sie klar erkennen. Beispielsweise erfordern PageCache und anderer Speicher, der vom Betriebssystem einheitlich zurückgefordert wird, aufdringliche Änderungen am Code, wie z. B. das Hinzufügen von Flush(. ) an den Appender von Log4J, um sync() regelmäßig aufzurufen.

https://stackoverflow.com/questions/11829922/logback-file-appender-doesnt-flush-immediately

Das ist sehr unrealistisch.

Das ACK-Container-Service-Team hat die feinkörnige Planungsfunktion Koordinator QoS eingeführt .

Auf Kubernetes implementiert, um die Speicherparameter des Betriebssystems zu steuern:

Wenn die differenzierte SLO-Kolokation im Cluster aktiviert ist, priorisiert das System die Speicher-QoS latenzempfindlicher LS-Pods (Latency-Sensitive) und verzögert das Timing der LS-Pods, die das Speicherrecycling auf der gesamten Maschine auslösen.

In der Abbildung unten stellt „memory.limit_in_bytes“ die Obergrenze der Speichernutzung dar, „memory.high“ stellt den Schwellenwert für die aktuelle Speichergrenze dar, „memory.wmark_high“ stellt den Schwellenwert für die Wiederverwendung des Speicherhintergrunds dar und „memory.min“ stellt den Schwellenwert für die Sperrung der Speichernutzung dar.

Figure/ack-koordinator bietet Speicher-QoS-Garantiefunktionen (Quality of Service) für Container

Wie kann das Speicher-Black-Hole-Problem behoben werden? Alibaba Cloud Container Service nutzt die verfeinerte Planungsfunktion und verlässt sich auf das Open-Source-Projekt Koordinator, das QoS-Garantiefunktionen (Quality of Service) für Container bereitstellt und so die Speichergerechtigkeit verbessert Ressourcen unter der Voraussetzung, dass die Speicherleistung der Anwendung zur Laufzeit fair ist. In diesem Artikel wird die QoS-Funktion des Containerspeichers vorgestellt. Detaillierte Anweisungen finden Sie unter Containerspeicher-QoS [ 3] .

Container unterliegen bei der Speichernutzung hauptsächlich den folgenden zwei Einschränkungen:

1) Eigenes Speicherlimit: Wenn sich der eigene Speicher des Containers (einschließlich PageCache) der Obergrenze des Containers nähert, wird das Container-dimensionale Speicherrecycling ausgelöst. Dieser Prozess wirkt sich auf die Speicheranwendung und die Freigabeleistung von Anwendungen innerhalb des Containers aus. Wenn die Speicheranforderung nicht erfüllt werden kann, wird der Container-OOM ausgelöst.

2) Knotenspeicherlimit: Wenn der Containerspeicher überverkauft ist (Speicherlimit> Anforderung) und die gesamte Maschine nicht über genügend Speicher verfügt, wird ein globales Speicherrecycling in der Knotendimension ausgelöst. Dieser Prozess hat große Auswirkungen auf die Leistung und kann in extremen Fällen auftreten , führt sogar dazu, dass die gesamte Maschine abnormal ist. Wenn das Recycling nicht ausreicht, wird der Container für OOM Kill ausgewählt.

Um die oben genannten typischen Probleme mit dem Containerspeicher zu beheben, bietet ack-koordinator die folgenden erweiterten Funktionen:

1) Wasserstand für Containerspeicher-Hintergrundrecycling: Wenn die Pod-Speichernutzung nahe am Grenzwert liegt, wird ein Teil des Speichers asynchron im Hintergrund recycelt, um die durch die direkte Speicherrecycling verursachten Leistungseinbußen zu mildern.

2) Container-Speichersperre-Recycling/Begrenzung des Wasserstands: Implementieren Sie ein gerechteres Speicher-Recycling zwischen Pods. Wenn die Speicherressourcen der gesamten Maschine nicht ausreichen, wird dem Recycling von Speicher von Pods mit Speicherüberbeanspruchung Priorität eingeräumt (Speichernutzung > Anforderung), um einzelne zu vermeiden Pods, die einen Gesamtausfall verursachen. Die Qualität der Maschinenspeicherressourcen hat sich verschlechtert.

3) Differenzierte Garantie für das gesamte Speicherrecycling: Im BestEffort-Szenario mit überverkauftem Speicher wird der Sicherstellung der Speicherlaufqualität von garantierten/burstablen Pods Vorrang eingeräumt.

Einzelheiten zu den Kernel-Funktionen, die durch die Speicher-QoS des ACK-Containers aktiviert werden, finden Sie in der Übersicht über Kernelfunktionen und Schnittstellen von Alibaba Cloud Linux [ 4] .

Nachdem im ersten Schritt der Beobachtung das Problem des Containerspeicher-Schwarzen Lochs entdeckt wurde, kann die ACK-Feinplanungsfunktion mit der gezielten Auswahl speicherempfindlicher Pods kombiniert werden, damit die Containerspeicher-QoS-Funktion die Closed-Loop-Reparatur abschließen kann.

Referenzdokumentation:

[1] ACK SysOM-Funktionsbeschreibungsdokument

https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/user-guide/sysom-kernel-level-container-monitoring?spm=a2c4g.11186623.0.0.5376162eZWAPFU

[2] Best-Practice-Dokumentation

https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/user-guide/use-sysom-to-locate-container-memory-issues?spm=a2c4g.11186623.0.0.197c162eyFPY5I

[3] Chinesische Drachenechsen-Gemeinschaft

https://mp.weixin.qq.com/s/b5QNHmD_U0DcmUGwVm8Apw

[4] Internationaler Sender Englisch

https://www.alibabacloud.com/blog/sysom-container-monitoring-from-the-kernels-perspective_600792

Verwandte Links:

[1] Cadvisor-Code

https://github.com/google/cadvisor/blob/50b23f4ed9bc53cf068316b67bee04c4145f1e73/info/v1/container.go#L391