Analysieren von Argumenten für und gegen das Festlegen von Auslagerungsspeicher auf Cloud-Instanzen

Wenn Sie einen Streit mit einem Linux-Benutzer beginnen möchten, fragen Sie nach swap Erinnerung. Manche loben es als Polster oder Sicherheitsnetz, andere verunglimpfen es als Krücke und Zerstörer der Systemleistung. Der in den 1960er Jahren entstandene Auslagerungsspeicher hat sich im Laufe der Jahre unter Linux weiterentwickelt, um zwei wesentliche Funktionen zu erfüllen:

• Notspeicher, wenn ein System seinen gesamten Arbeitsspeicher verbraucht und noch mehr benötigt
• Ein Parkplatz für selten genutzte Speicherseiten, die wertvollen System-RAM beanspruchen

Viele Linux-Distributionen, einschließlich Red Hat, empfehlen Auslagerungsspeicher für alle Systeme. Wenn Sie sich jedoch die meisten Cloud-Instanzen verschiedener Distributionen ansehen, stellen Sie fest, dass kein Auslagerungsspeicher vorhanden ist.

[Das könnte Ihnen auch gefallen: Linux-Fehlerbehebung 101:Systemleistung]

Swap-Übersicht

Swap existiert auf den meisten Systemen als Partition auf einer Festplatte. Nach der Partitionierung formatieren Administratoren die Partition mit mkswap , aktivieren Sie es mit swapon , und der Kernel sieht sofort den verfügbaren Auslagerungsspeicher. Systeme ohne verfügbare Partition können eine Auslagerungsdatei verwenden, die einfach eine Datei auf einem bestehenden Dateisystem ist, die mit mkswap formatiert ist und aktiviert.

Beide Methoden funktionieren gut, aber das Platzieren einer Auslagerungsdatei auf einer Partition führt zu einer besseren Leistung, da Sie den Overhead einer Auslagerungsdatei auf einer vorhandenen Partition überspringen.

Wenn der System-RAM knapp ist, kann Linux Speicherseiten im Swap speichern, um zu vermeiden, dass Prozesse beendet und das System zum Absturz gebracht werden. Festplatten sind viel langsamer als System-RAM, und dies verringert die Systemleistung, bis System-RAM freigegeben wird. Wenn die Speichernutzung bis zu dem Punkt ansteigt, an dem System-RAM und Swap vollständig erschöpft sind, erscheint der Out of Memory (OOM)-Killer und beginnt mit dem Beenden von Prozessen, bis genügend RAM verfügbar ist.

Der langjährige Ratschlag zur Auslagerungsgröße ist doppelt so groß wie der Arbeitsspeicher Ihres Systems. Weisen Sie beispielsweise 2 GB Swap für Systeme mit 1 GB System-RAM zu. Obwohl dieses Verhältnis für kleinere Systeme gut funktioniert, lässt es sich nicht auf Systeme mit Hunderten von Gigabyte System-RAM skalieren.

Argumente für Swap on Cloud

Der Aufstieg von Microservices (kleine, miteinander verbundene Dienste, die eine große Anwendung bilden) veranlasste Unternehmen, eine größere Anzahl kleinerer Instanzen bereitzustellen. Kleinere Instanzen verfügen über weniger System-RAM, was das Risiko erhöht, dass der gefürchtete OOM-Killer auftaucht und Prozesse beendet, bis das System über genügend freien Speicher verfügt.

Das Hinzufügen von Swap zu diesen Systemen hilft auf zweierlei Weise:

• Erstens können Prozesse in Zeiten hoher Auslastung kurzzeitig aus dem System-RAM in den Swap platzen. Administratoren erfahren über diese Ereignisse von ihren Überwachungssystemen und haben Zeit, den Grund für den Burst zu untersuchen, während er auf dem System auftritt. Im Falle von Speicherlecks können Entwickler den Prozess untersuchen, um zu verstehen, was schief gelaufen ist, während er noch am Leben ist. Dies kann auch ein Signal dafür sein, dass Administratoren größere Instanztypen für ihre wachsende Anwendung benötigen.
• Zweitens wacht der Linux-Kernel über selten verwendete Speicherseiten und sendet sie zum Auslagern, um wertvollen System-RAM zu sparen. Die sysctl Einstellung von vm.swappiness steuert den Wunsch des Kernels, Speicherseiten zum Austauschen zu pushen. Dies könnte einer Cloud-Instanz helfen, indem die aktivsten Seiten im System-RAM gehalten werden, während selten verwendete Seiten in den Arbeitsspeicher verschoben werden.

Der Fall gegen Swap on Cloud

Die Analogie „Haustiere vs. Vieh“ taucht häufig auf, wenn über Cloud-Instanzen gesprochen wird, und Administratoren verbieten Swap, da sie eine fehlerhafte Instanz automatisch durch eine neue ersetzen können. Im Laufe der Zeit zeigen ihre Überwachungsmetriken eine Zunahme der Instanzen, die ersetzt werden müssen, weil der OOM-Killer ihre Anwendung offline genommen hat. Die Lösung könnten größere Instanzen oder eine weitere Untersuchung von Speicherlecks unter Last sein. Systemd wird diese Prozesse nach Möglichkeit auch schnell neu starten.

Die Auswahl eines Auslagerungsspeicherorts auf Cloud-Instanzen erfordert mehr Überlegung und Planung. Auf physischen Servern ist der Austausch auf einer lokal angeschlossenen Non-Volatile Memory Express (NVMe)-Festplatte schnell genug, aber was ist mit einer Cloud-Instanz mit externem Speicher, wie z. B. Elastic Block Storage (EBS) von AWS? Die Leistung auf EBS variiert je nach gewähltem EBS-Typ und Ihren Nachbarn im System. Swap auf einem Remote-Speichersystem kann zu einer schlechten Instanzleistung führen, wenn das System seinen RAM überläuft. Administratoren können sich dafür entscheiden, den Austausch wegzulassen und diese Instanzen zu ersetzen, wenn ihr RAM überläuft, anstatt sich mit schlecht funktionierenden Server-Handling-Anforderungen herumzuschlagen.

Schließlich werden viele Cloud-Instanzen Teil von Kubernetes- und OpenShift-Clustern und haben eine Herausforderung beim Umgang mit Auslagerungsspeicher. Es gibt ein lang andauerndes GitHub-Problem bezüglich des angemessenen Umgangs mit Auslagerungsspeicher, da es die Speicherabrechnung für Container durcheinander bringt. Es gibt Problemumgehungen, aber der Auslagerungsspeicher wird auf diesen Systemen im Allgemeinen übersprungen.

Cloudinstanzen mit Swap bereitstellen

Sollten Sie entscheiden, dass die Bereitstellung von Auslagerungsspeicher für Ihre Anwendungen von Vorteil ist, gibt Ihnen cloud-init die Möglichkeit, Auslagerungsspeicher beim ersten Start mithilfe der mounts bereitzustellen Modul. Fügen Sie einfach ein paar Zeilen zu Ihren bestehenden Cloud-Config-Benutzerdaten hinzu:

swap:
    filename: /swapfile
    size: auto
    maxsize: 4294967296

Diese Konfiguration weist cloud-init an, eine Auslagerungsdatei unter /swapfile zu erstellen mit einer automatischen Größe von 4 GB oder weniger. Die Formel für die automatische Swap-Größenbestimmung befindet sich im Quellcode von cloud-init:

formulas = [
    # < 1G: swap = double memory
    (1 * GB, lambda x: x * 2),
    # < 2G: swap = 2G
    (2 * GB, lambda x: 2 * GB),
    # < 4G: swap = memory
    (4 * GB, lambda x: x),
    # < 16G: 4G
    (16 * GB, lambda x: 4 * GB),
    # < 64G: 1/2 M up to max
    (64 * GB, lambda x: x / 2),
]

Die empfohlene Swap-Größe von Red Hat weicht geringfügig ab:

• 2 GB oder weniger System-RAM :2x RAM
• Über 2 GB bis 8 GB : 1x RAM
• Über 8 GB bis 64 GB :Mindestens 4 GB
• Über 64 GB :mindestens 4 GB

Den Auslagerungsspeicher (in Byte) können Sie manuell mit size: angeben Parameter
in der Cloud-Config:

swap:
    filename: /swapfile
    size: 2147483648  # 2 GiB

Provisioning-Swap auf einer bestehenden Cloud-Instanz

Für vorhandene Instanzen ist eine Auslagerungsdatei häufig die einfachste Methode zum Aktivieren des Auslagerungsspeichers. Platzieren Sie in diesem Beispiel eine 2-GB-Auslagerungsdatei in /swapfile :

# BTRFS only #################################################################
# We must disable copy-on-write updates for swap files on btrfs file systems.
# The 'swapon' step fails if you skip these steps.
truncate -s 0 /swapfile
chattr +C /swapfile
# BTRFS only #################################################################

# A 2 GiB swap file.
dd if=/dev/zero of=/swapfile bs=1MiB count=2048

# Set the correct permissions on the swap file.
chmod 0600 /swapfile

# Format the swapfile.
mkswap /swapfile

# Enable the swapfile.
swapon /swapfile

# Add it to /etc/fstab to enable it after reboot.
echo "/swapfile none swap defaults 0 0" >> /etc/fstab

Prüfen Sie, ob Ihr Auslagerungsspeicher bereit ist:

$ cat /proc/swaps
Filename        Type    Size      Used    Priority
/swapfile       file    2097148   0       -2

[ Kostenloser Online-Kurs:Technischer Überblick zu Red Hat Enterprise Linux. ] 

Schluß

Auslagerungsspeicher bietet zwei wertvolle Vorteile:

• Ein Sicherheitspolster, wenn die RAM-Nutzung des Systems auf ein gefährliches Niveau ansteigt
• Ein Parkplatz für selten genutzte Speicherseiten, die wertvollen Platz im System-RAM einnehmen 

Dieses Sicherheitspolster geht mit Leistungseinbußen einher, da die Speicherauslagerung auf Festplatten im Vergleich zum Systemspeicher unglaublich langsam ist.

Bei Cloud-Bereitstellungen wird selten Swap-Speicher bereitgestellt, aber Swap hat dort immer noch Vorteile. Die Entscheidung für die Bereitstellung von Swap ermöglicht ein Sicherheitspolster, wenn sich Anwendungen schlecht verhalten, aber es könnte dazu führen, dass eine Anwendung langsam ausgeführt wird, bis die Probleme mit dem Speicherverbrauch behoben sind. Durch das Überspringen von Swap wird das Polster entfernt, aber sichergestellt, dass eine fehlerhafte Anwendung sofort gestoppt wird. Cloud-Administratoren müssen einen Plan haben, um mit diesen Situationen umzugehen.

Glücklicherweise erscheint cloud-init auf den meisten Cloud-Instanzen und ermöglicht die Erstellung von Auslagerungsdateien mit nur wenigen YAML-Zeilen. Der Auslagerungsspeicher lässt sich auch nach der Bereitstellung einfach mit einfachen Shell-Befehlen oder Skripts konfigurieren.

Unabhängig davon, ob Sie Auslagerungsspeicher bereitstellen oder darauf verzichten, stellen Sie sicher, dass Sie einen Plan haben, wenn das Schlimmste eintritt. Systeme angemessen überwachen und einen ganzheitlichen Überblick über die Anwendung behalten, die sie bedienen.