Debian 12 auf einem VPS mit wenig RAM ausführen, ohne dass OOM-Abstürze MySQL zum Absturz bringen

Ein VPS mit wenig Arbeitsspeicher kann Debian 12 und eine Datenbank ausführen, die Stabilität hängt jedoch von der gesamten Arbeitslast ab – nicht nur vom konfigurierten Cache von MySQL. Wenn der verfügbare Arbeitsspeicher knapp wird, kann Linux den Out-of-Memory-Killer (OOM-Killer) aufrufen, der einen Prozess beendet, um das restliche System zu schützen. Handelt es sich bei diesem Prozess um die Datenbank, kann dies wie ein zufälliger Absturz aussehen. Ziel ist es, anhaltenden Speicherdruck zu vermeiden und zu überprüfen, welcher Prozess vom Kernel tatsächlich beendet wurde. Keine Systemeinstellung kann garantieren, dass OOM-Ereignisse niemals auftreten.

Läuft auf Debian 12 MySQL oder MariaDB?

Überprüfen Sie den Server, bevor Sie seine Konfiguration ändern. Debian 12 (Bookworm) verwendet MariaDB als Standardpaket default-mysql-server; Oracle MySQL wird separat installiert. In den Paketinformationen von Debian ist MariaDB als Serverabhängigkeit dieses Metapakets aufgeführt. Führen Sie folgenden Befehl aus:

mariadb --version
mysql --version
dpkg-query -W -f='${Package} ${Version}\n' mariadb-server mysql-community-server 2>/dev/null

Verwenden Sie die folgenden MariaDB-Anweisungen nur, wenn MariaDB installiert ist. Oracle MySQL verwendet zwar häufig ähnlich aussehende Optionsnamen, jedoch können sich Paketstrukturen, Dienstnamen, verfügbare Variablen und Standardwerte unterscheiden. Konsultieren Sie das Handbuch für die exakt installierte MySQL-Version.

Primäre Referenzen: Das Standard-MySQL-Server-Paket von Debian Bookworm und das MySQL 8.0-Speicherverwendungshandbuch .

Woran erkennt man, ob ein Speichermangel die Datenbank lahmgelegt hat?

Unterscheiden Sie zunächst zwischen einem Kernel-OOM-Kill, einem Datenbankfehler, einem Neustart des Dienstes, einem Neustart des Systems oder einem Festplattenproblem. Unter Debian journalctlwird dazu das Journal von systemd gelesen. Suchen Sie im aktuellen Bootvorgang nach dem Dienstprotokoll von MariaDB.

sudo journalctl -k -b --no-pager | grep -Ei 'out of memory|oom-kill|killed process'
sudo journalctl -u mariadb -b --no-pager -n 100
sudo systemctl status mariadb --no-pager

Wenn im Kernel-Log mariadbdnach mysqldeiner OOM-Meldung ein Eintrag erscheint, deutet dies auf einen Speicherabsturz hin. Falls kein passender Eintrag vorhanden ist, überprüfen Sie das Fehlerprotokoll des Dienstes sowie den Neustart- oder Überwachungsverlauf des Anbieters. Protokolle sind nach einem Neustart möglicherweise nicht verfügbar, wenn die Protokollierung nicht persistent ist. Ein Managed-VPS-Anbieter stellt unter Umständen nur einen Teil der Host-Diagnosedaten bereit.

Erfassen Sie eine Basislinie, während der Server unter repräsentativem Datenverkehr steht, nicht nur im Leerlauf:

free -h
swapon --show
vmstat 1
ps -eo pid,comm,rss,%mem --sort=-rss | head

vmstatBeobachten Sie in der Ausgabe sidie soSpalten „Swap-In“ und „Swap-Out“ auf anhaltende Swap-Aktivität. Eine Swap-Zuweisung ungleich Null allein ist kein Problem; anhaltendes Swapping in Verbindung mit langsamen Reaktionszeiten deutet jedoch auf Speicherengpässe hin. Linux dokumentiert die Behandlung von Speichermangel als letzte Maßnahme, wenn der Speicher nicht ausreichend freigegeben werden kann. Siehe dazu die Konzepte zur Speicherverwaltung des Linux-Kernels und das Handbuch zu journalctl von Debian .

Was sollte man vor dem Stimmen messen?

Protokollieren Sie den gesamten RAM-Verbrauch, die aktuelle und maximale Swap-Speichernutzung, die größten residenten Prozesse, Datenbankverbindungen und die normale Spitzenlast der Webanwendung. Die Datenbank teilt sich den Speicher mit Debian, dem Webserver, Anwendungsworkern, Überwachungsagenten und dem Dateisystemcache. Ein VPS kann auch ein Container- oder Cgroup-Speicherlimit haben, das niedriger ist als der physische RAM des Hosts; dimensionieren Sie die Datenbank-Caches entsprechend dem für den Dienst sichtbaren Speicherlimit, nicht anhand eines höheren Gesamtspeicherlimits des Hosts.

Überprüfen Sie für MariaDB die aktuellen speicherbezogenen Einstellungen und die Verbindungsspitzen:

sudo mariadb -e "SHOW VARIABLES WHERE Variable_name IN ('innodb_buffer_pool_size','max_connections','tmp_table_size','max_heap_table_size'); SHOW GLOBAL STATUS LIKE 'Max_used_connections'; SHOW GLOBAL STATUS LIKE 'Threads_connected';"

Der InnoDB-Pufferpool speichert Tabellen- und Indexseiten im Cache. Verbindungslimits und Abfragepuffer können den Speicherbedarf bei zunehmender gleichzeitiger Verarbeitung erhöhen. Vermeiden Sie es, jeden Verbindungspuffer so zu multiplizieren, max_connectionsals wäre jeder Puffer stets vollständig belegt. Berücksichtigen Sie jedoch ein sehr hohes Verbindungslimit als Risiko bei Lastspitzen. Der Speicherleitfaden von MariaDB empfiehlt, globale Caches, Verbindungspuffer und Engine-Einstellungen gemeinsam zu dimensionieren und weist insbesondere auf Anwendungsverbindungspools hin. Lesen Sie den MariaDB-Leitfaden zur Speicherzuweisung und den Leitfaden zum Umgang mit zu vielen Verbindungen .

Wie dimensioniert man MariaDB richtig auf einem kleinen VPS?

Nehmen Sie jeweils nur eine Änderung vor, erstellen Sie eine Kopie der Originalkonfiguration und testen Sie während eines Wartungsfensters, ob ein Neustart Auswirkungen auf die Benutzer hätte. Die mit Debian bereitgestellte MariaDB-Konfiguration enthält üblicherweise Dateien unter /etc/mysql/mariadb.conf.d/; überprüfen Sie die aktiven Include-Verzeichnisse Ihrer Installation, bevor Sie Änderungen vornehmen. Eine kleine, einfach zu entfernende Datei lässt sich leichter entfernen als die Hauptdatei des Herstellers zu ersetzen.

sudo cp -a /etc/mysql/mariadb.conf.d /root/mariadb.conf.d.backup
sudoedit /etc/mysql/mariadb.conf.d/90-low-memory.cnf

Für einen Shared VPS mit ca. 1 GiB RAM ist das Folgende lediglich ein vorsichtiges Startbeispiel – kein allgemein sicheres Profil. Passen Sie die Werte entsprechend der gemessenen maximalen Speicherauslastung, der Datenbankgröße, der Arbeitslast und dem für Betriebssystem und Anwendung verbleibenden RAM an.

[mariadb]
innodb_buffer_pool_size = 192M
max_connections = 30
tmp_table_size = 16M
max_heap_table_size = 16M

MariaDB liest beim Start Einstellungen aus Optionsdateien. Überprüfen Sie die von Ihrer Version unterstützten Abschnittsnamen und deren Werte. Falls die Datei nicht geladen werden kann, entfernen Sie das Drop-in und prüfen Sie das Journal. Ein Neustart der Datenbank unterbricht bestehende Verbindungen; planen Sie ihn daher entsprechend.

sudo systemctl restart mariadb
sudo systemctl is-active mariadb
sudo journalctl -u mariadb -b --no-pager -n 80
sudo mariadb -e "SELECT @@innodb_buffer_pool_size, @@max_connections;"

Beurteilen Sie das Ergebnis anhand von Stabilität und Servicequalität. Ein kleinerer Pufferpool kann die Anzahl der Cache-Treffer verringern und die Festplattenzugriffe erhöhen. Eine max_connectionszu starke Reduzierung kann hingegen zu Fehlern aufgrund zu vieler Verbindungen führen. Vergleichen Sie die Werte Max_used_connectionsmit dem konfigurierten Limit und überprüfen Sie die Größe des Anwendungspools, bevor Sie das Limit erneut ändern. Falls die Datenbank auch bei normalem Spitzenverkehr weiterhin abstürzt oder sich die Antwortzeit durch anhaltendes Auslagern auf die Festplatte verschlechtert, wechseln Sie zu einer größeren RAM-Ebene oder trennen Sie die Datenbank von der Anwendung.

Kann ein Swap-Mechanismus einen OOM-Absturz verhindern?

Swap-Speicher bietet Linux einen langsameren Speicherbereich zum Auslagern von Speicherseiten und kann kurzzeitige Lastspitzen abfangen. Er fügt jedoch keinen schnellen Arbeitsspeicher hinzu, behebt keine Speicherlecks und macht einen unterdimensionierten VPS nicht für dauerhafte Arbeitslasten geeignet. Intensives Auslagern kann dazu führen, dass sowohl die Datenbank als auch die Anwendung nicht mehr reagieren. Prüfen Sie vor der Erstellung eines Swap-Speichers, ob Ihr Anbieter diesen unterstützt und ob der VPS über ausreichend Speicherplatz verfügt.

Sofern unterstützt, kann eine 1 GiB große Auslagerungsdatei wie folgt erstellt werden. Passen Sie die Größe gemäß den Anweisungen des Anbieters und dem verfügbaren Speicherplatz an und überprüfen Sie das Ergebnis jedes Befehls:

sudo fallocate -l 1G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
swapon --show

Um die Funktion nach einem Neustart zu aktivieren, fügen Sie diesen Eintrag hinzu, /etc/fstabnachdem Sie geprüft haben, ob bereits ein entsprechender Eintrag vorhanden ist:

/swapfile none swap sw 0 0

Überprüfen Sie anschließend die Datei sudo findmnt --verify --verboseund stellen Sie sicher, dass sie im Verzeichnis vorhanden ist swapon --show. Falls fallocatedas Dateisystem dies nicht unterstützt oder der Provider den Swap-Speicher blockiert, brechen Sie den Vorgang ab und verwenden Sie die vom Provider bereitgestellte Vorgehensweise. Deaktivieren Sie den OOM-Killer nicht und weisen Sie MySQL keine extrem hohe OOM-Schutzbewertung zu: Dies schafft keinen zusätzlichen Speicher und kann die übrigen Systeme eines kleinen VPS einem höheren Risiko aussetzen.

Woran erkennt man, dass die Änderungen funktioniert haben?

Beobachten Sie den VPS während mindestens einer normalen Auslastungsperiode. Ein aussagekräftiges Ergebnis weist mehrere Merkmale auf:

• Während der Arbeitslast, die zuvor den Vorfall ausgelöst hatte, wurden keine neuen Kernel-OOM-Kill-Einträge mehr verzeichnet.
• MariaDB bleibt aktiv und die Anzahl der Neustarts steigt nicht unerwartet an.
• vmstat 1Bei normalem Datenverkehr wird kein kontinuierliches Ein- und Auswechseln angezeigt.
• Die Anwendung reagiert weiterhin schnell, und die Spitzenwerte der Datenbankverbindungen bleiben ohne Verbindungsfehler unter dem neuen Grenzwert.
• Die Datensicherungen sind abgeschlossen und die Datenbankabfragen erfüllen weiterhin die für die Anwendung akzeptable Latenz.

Verwenden Sie nicht den Status „Der Dienst startet“ als einzigen Erfolgstest. Eine Einstellung, die MariaDB zwar am Laufen hält, das System aber zu ständigem Swapping zwingt, löst das zugrundeliegende Kapazitätsproblem nicht. Ebenso wenig validiert ein ruhiger Tag einen monatlichen Import, ein Backup, eine Lastspitze oder einen Batch-Job, der noch nicht ausgeführt wurde.

Wann ist eine Feinabstimmung nicht mehr die richtige Lösung?

Wählen Sie einen größeren VPS oder trennen Sie Workloads, wenn der Speicher trotz angemessener Cache- und Parallelitätsanpassungen weiterhin stark ausgelastet ist, die Swap-Aktivität anhält, die Abfragelatenz inakzeptabel wird oder die Anwendung wiederholt das neue Verbindungslimit erreicht. Auch die Datenbankgröße ist wichtig: Ein zu kleiner Pufferpool kann zwar Speicherspitzen vermeiden, aber die Festplatten-E/A zum neuen Flaschenhals machen. Wenn Anwendung und Datenbank abrupte, aber vorhersehbare Spitzen aufweisen, prüfen Sie zunächst, ob die Anwendung zu viele Verbindungen öffnet oder speicherintensive Prozesse gleichzeitig ausführt.

Bei Verwendung von Oracle MySQL anstelle der standardmäßigen MariaDB von Debian sollten Sie vor Anwendung dieser Beispiele den Dienstnamen, den Pfad zur Optionsdatei und die Speichervariablen anhand des jeweiligen Serverhandbuchs überprüfen. Bewahren Sie auf beiden Systemen getestete Backups auf und ändern Sie jeweils nur eine Variable. Das zuverlässige Ergebnis ist keine Garantie dafür, dass Linux niemals eine Speichermangelbehandlung auslöst; es belegt lediglich, dass der VPS über ausreichend Kapazität für seine tatsächliche Spitzenlast verfügt und dass MySQL oder MariaDB nicht mehr wiederholt betroffen ist.

Weitere primäre Referenzen: MariaDBs Leitfaden zur Fehlerbehebung beim Start , in dem darauf hingewiesen wird, dass der Server auch Speicher für andere Engines, Verbindungspuffer und das Betriebssystem benötigt, sowie das MySQL 8.0 Referenzhandbuch .