Debian 12 auf einem VPS mit wenig RAM: So reduzieren Sie MySQL-Speicherfehler

Das Risiko, dass MySQL auf einem Debian 12 VPS mit wenig RAM aufgrund eines OOM-Fehlers abstürzt, lässt sich reduzieren, indem die Ursache ermittelt, der Arbeitsspeicher auf alle Dienste verteilt, die Datenbank-Parallelität begrenzt und, sofern vom VPS unterstützt, Swap-Speicher bereitgestellt wird. Ein kleinerer InnoDB-Pufferpool allein reicht nicht aus. Weder Swap-Speicher noch eine OOM-Schutzeinstellung garantieren, dass eine überdimensionierte Arbeitslast weiterhin ausgeführt werden kann.

Diese Anleitung wurde am 9. Oktober 2026 unter Verwendung von Debian 12 „bookworm“, Linux 6.1 und der Oracle MySQL 8.0/8.4-Dokumentation erstellt. Die unten aufgeführten Einstellungen dienen als beispielhafte Ausgangspunkte und stellen weder Benchmark-Ergebnisse noch eine universelle Konfiguration dar. Sichern Sie die Datenbank und die Konfiguration vor Änderungen und planen Sie Datenbankneustarts, wenn eine Ausfallzeit akzeptabel ist.

1. Identifizieren Sie den Server, bevor Sie die MySQL-Einstellungen kopieren.

Bestätigt: Das Standardpaket „default-mysql-server“ von Debian 12 ist von MariaDB abhängig. Ein VPS, der als „MySQL“ beschrieben wird, kann tatsächlich MariaDB verwenden, während ein anderer möglicherweise Oracle MySQL aus einem separaten Repository oder Container nutzt.

mysql --version
systemctl status mysql mariadb

Der erste Befehl identifiziert den Client, nicht aber den laufenden Server. Stellen Sie eine Verbindung mit Ihrem Datenbankadministratorkonto her und führen Sie folgenden Befehl aus:

SELECT VERSION(), @@version_comment;

Verwenden Sie Ihre bestehende Authentifizierungsmethode. Debian MariaDB-Installationen erlauben möglicherweise die lokale Administration mit `sudo` sudo mysql. Notieren Sie sich die Serverversion und den tatsächlichen Dienstnamen. Nachfolgende Dienstbefehle verwenden mysql.service`sudo`; ersetzen Sie `sudo` mariadb.servicegegebenenfalls. Fügen Sie der MariaDB-Konfiguration keine Oracle-spezifischen Variablen hinzu.

2. Bestätigen Sie, dass die Abschaltung auf ein OOM-Ereignis zurückzuführen war.

Häufiges Missverständnis: Jeder unerklärte Neustart der Datenbank führt zu einem Speichermangel. Auch Authentifizierungsfehler, Festplattenauslastung, ungültige Konfigurationen, Abstürze und Neustarts durch Administratoren können den Dienst unterbrechen.

sudo journalctl -k -b
sudo journalctl -u mysql.service --since today
sudo journalctl -u systemd-oomd --since today

Suchen Sie im Zeitraum um den Vorfall herum nach Kernel-Meldungen, die auf einen Speichermangel und den beendeten Prozess hinweisen, und vergleichen Sie diese Meldungen mit dem Dienstprotokoll. Prüfen Sie außerdem das Datenbank-Fehlerprotokoll, falls Ihr Paket die Fehler in eine Datei statt in das Journal schreibt. Wenn der Vorfall vor einem Neustart auftrat, prüfen Sie den vorherigen Neustart, journalctl -k -b -1sofern Protokolle verfügbar sind. Fehlende historische Protokolle lassen die Ursache unbestätigt.

Ein Benutzerspeichermanager kann auch Workloads beenden. Das Handbuch zu systemd-oomd von Debian beschreibt Eingriffe bei Speichermangel, bevor es zu einem Kernel-OOM-Ereignis kommt. Prüfen Sie, ob systemd-oomd installiert und aktiv ist, anstatt anzunehmen, dass jeder Debian-VPS es verwendet.

Überprüfen Sie auch die Systemd-Limits:

systemctl show mysql.service \
  -p ControlGroup -p MemoryCurrent -p MemoryHigh \
  -p MemoryMax -p MemorySwapMax

Auf einem System mit cgroup v2 verwenden Sie den gemeldeten Pfad zur ControlGroup, um die Einträge memory.eventsunter ` memory.max/var/log/ cgroup` auszulesen . Überprüfen Sie auch übergeordnete cgroups. Die Linux-Dokumentation zu cgroup v2 erläutert diese Zähler und Grenzwerte. Eine cgroup kann ihren zugewiesenen Speicher überschreiten, selbst wenn der Host noch Kapazität hat. Ein Zähler protokolliert Abbrüche, diese müssen jedoch zusammen mit Grenzwerten und Protokollen interpretiert werden, um die Ursache zu ermitteln.memory.swap.max/sys/fs/cgroupoom_kill

3. Messen Sie den gesamten VPS, nicht nur den Pufferpool.

free -h
ps -eo pid,comm,rss --sort=-rss
vmstat 1

Sammeln Sie Beobachtungen während des normalen Datenverkehrs und der mit Fehlern verbundenen Prozesse. freeKonzentrieren Sie sich dabei auf den verfügbaren Speicher, nicht nur auf die Spalte „Freier Speicher“. Das kostenlose Debian- Handbuch beschreibt den verfügbaren Speicher als Schätzung dessen, was ohne Auslagerung genutzt werden kann. RSS-Werte in der Prozessliste werden in KiB angegeben; ihre Addition kann zu einer doppelten Zählung des gemeinsam genutzten Speichers führen.

Bestätigt: MySQL allokiert Speicher über den InnoDB-Pufferpool hinaus, einschließlich verbindungs- und abfragebezogener Speicherbelegungen. Die MySQL-Speicherreferenz dokumentiert diese Komponenten. Eine auf konfigurierten Puffern basierende Formel sollte als Planungsschätzung und nicht als exakte Obergrenze betrachtet werden.

Maßnahme: Reservieren Sie Speicherkapazität für Kernel, Web-Worker, Monitoring, Backups und temporäre Datenbankoperationen. Die gängige Empfehlung, InnoDB den größten Teil des RAM zuzuweisen, ist auf einem Shared VPS ohne Anpassung ungeeignet. Wenn PHP-Worker oder ein Build-Prozess den verfügbaren Speicher belegen, optimieren oder verschieben Sie diese Workload, anstatt MySQL wiederholt zu verkleinern.

4. Swap-Speicher als Puffer hinzufügen, nicht als Ersatz für RAM.

Kontextabhängig: Swap kann vorübergehenden Speicherdruck durch anonymen Speicher abfangen, aber dauerhaftes Auslagern kann Abfragen zu stark verlangsamen. Ein containerbasierter VPS kann Swap einschränken, und ein Dienst MemorySwapMaxkann dessen Nutzung verhindern, selbst wenn der Host über Swap verfügt.

swapon --show
free -h
df -h /
findmnt -no FSTYPE /

Falls kein Swap-Speicher vorhanden ist, der Provider dies zulässt und ausreichend Speicherplatz auf der Festplatte vorhanden ist, erstellt der folgende Befehl eine 1 GiB große Swap-Datei auf einem geeigneten lokalen Dateisystem wie z. B. ext4. Führen Sie den Befehl nicht aus, wenn die Datei `/swapfile` bereits existiert. Prüfen Sie vorher die dateisystemspezifischen Anforderungen; Btrfs benötigt eine geeignete Konfiguration für eine Swap-Datei ohne Copy-on-Write.

sudo dd if=/dev/zero of=/swapfile bs=1M count=1024 status=progress
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
swapon --show

Erst nach erfolgreicher Aktivierung fügen Sie diesen Eintrag einmalig hinzu zu /etc/fstab:

/swapfile none swap sw 0 0

Das Debian-Swapon-Handbuch dokumentiert die Einschränkungen der Auslagerungsdatei. Falls die Aktivierung in der VPS-Umgebung verweigert wird, fragen Sie Ihren Anbieter nach unterstützter Auslagerungsdatei oder erhöhen Sie den Arbeitsspeicher Ihres Tarifs; speichern Sie eine fehlgeschlagene Konfiguration nicht.

Kopieren Sie nicht die Einstellung „Swappiness auf Null setzen“ als OOM-Schutz. Die Kernel-VM-Dokumentation definiert Swappiness als eine Einstellung zur Speicherbereinigung. Sie erzeugt keinen zusätzlichen Speicher und legt kein Speicherlimit für die Datenbank fest. Belassen Sie die Einstellung zunächst unverändert und beobachten Sie das Verhalten.

5. Legen Sie eine moderate Datenbankbasislinie fest

Betrachten wir beispielsweise einen 1-GiB-VPS mit einer geringen InnoDB-Workload und einigen Anwendungsworkern. Die folgenden Werte sind lediglich Kandidaten für die Bewertung und kein Beweis dafür, dass diese Workload geeignet ist:

[mysqld]
innodb_buffer_pool_size=128M
max_connections=20
tmp_table_size=16M
max_heap_table_size=16M

Fügen Sie die Serveroptionen in eine Konfigurationsdatei ein, die von Ihrer Installation eingebunden wird. Ein Oracle MySQL-Paket kann beispielsweise eine solche Datei enthalten /etc/mysql/mysql.conf.d/; Debian MariaDB verwendet üblicherweise eine andere /etc/mysql/mariadb.conf.d/. Überprüfen Sie die vorhandenen Include-Anweisungen und erstellen Sie eine Sicherungskopie. Die Dokumentation zur MySQL -Optionsdatei erläutert die Serveroptionsgruppen und die Dateiverwaltung.

Ein 128 MiB großer Pufferpool begrenzt den Cache, nicht den gesamten Datenbankspeicher. Ein Verbindungslimit von 20 kann zu restriktiv sein, wenn mehrere Anwendungsinstanzen jeweils einen eigenen Pool nutzen. Umgekehrt können 20 gleichzeitige, rechenintensive Abfragen den VPS überlasten. Halten Sie die Gesamtzahl der Anwendungspools unterhalb des vorgesehenen Serverlimits, lassen Sie ausreichend Platz für administrative Zugriffe und beobachten Sie abgelehnte Verbindungen.

Die oben genannten allgemeinen Variablen sind auch in der Systemvariablenreferenz von MariaDB aufgeführt , das Verhalten temporärer Tabellen variiert jedoch je nach Produkt und Version. Vermeiden Sie es, die globalen Sortier-, Join- oder Lesepuffer als allgemeine Leistungsoptimierung auf ressourcenbeschränkten Systemen zu erhöhen.

6. Temporäre Tabellen und Parallelität gemeinsam steuern

Häufiges Missverständnis: Die Annahme, dass durch diese Einstellung tmp_table_size=16Mder gesamte Abfragespeicher auf 16 MiB begrenzt wird, ist falsch. Mehrere Sitzungen, mehrere temporäre Tabellen und andere Ausführungszuweisungen können gleichzeitig bestehen.

Für Oracle MySQL 8.4 ist ein weiterer beispielhafter Ausgangspunkt:

temptable_max_ram=64M
temptable_max_mmap=0

Fügen Sie diese Einstellungen erst nach Bestätigung der Produktunterstützung in die bestehende [mysqld]Gruppe ein. Sie regeln den Schwellenwert für den gemeinsam genutzten Arbeitsspeicher der TempTable-Engine und die Verwendung speicherabgebildeter temporärer Dateien. Sie begrenzen weder den gesamten mysqld-Prozess noch alle Thread-lokalen Speicherzuweisungen. Niedrigere Schwellenwerte können zu einer stärkeren Auslagerung auf die Festplatte führen.

Die Dokumentation zu temporären Tabellen in MySQL 8.4 erläutert diese Beschränkungen. MySQL 8.0 verhält sich versionsabhängig: Die Beschränkung temptable_max_mmapwurde in Version 8.0.23 eingeführt und tmp_table_sizeist ab Version 8.0.28 als individuelle TempTable-Beschränkung implementiert. Konsultieren Sie die MySQL 8.0-Referenz, bevor Sie dieselben Einstellungen anwenden. Kopieren Sie diese Oracle-spezifischen Optionen nicht nach MariaDB.

Maßnahme: Begrenzen Sie sich überschneidende Berichtsabfragen, Hintergrundprozesse und Sicherungs- oder Importaufträge. Überprüfen Sie Abfragepläne und Indizes, wenn ein bestimmter Vorgang zu hoher Auslastung führt. Das Verlagern von ressourcenintensiven Aufgaben aus Spitzenzeiten kann Abhilfe schaffen. Sollte die normale, gleichzeitige Nachfrage die Kapazität weiterhin übersteigen, ist zusätzlicher Arbeitsspeicher oder die Trennung der Datenbank der nächste geeignete Schritt.

7. Änderungen überprüfen und absichtlich neu starten

Bei Oracle MySQL-Versionen, die diese Option unterstützen, überprüfen Sie die Konfiguration vor dem Neustart:

sudo mysqld --validate-config

Verwenden Sie denselben Pfad zur Standarddatei und dieselben relevanten Startargumente wie der Dienst, falls dieser nicht die Standardkonfigurationserkennung nutzt. Die MySQL-Validierungsreferenz weist darauf hin, dass die Validierung nicht jedes Subsystem initialisiert. Ein erfolgreiches Bestehen ist kein Test der Arbeitslastkapazität. Gehen Sie nicht davon aus, dass MariaDB diese Oracle-Option unterstützt.

Starten Sie den eigentlichen Dienst während des geplanten Zeitfensters neu, überprüfen Sie dann den Startvorgang und fragen Sie die effektiven Werte ab:

sudo systemctl restart mysql.service
systemctl status mysql.service
sudo journalctl -u mysql.service --since today

SHOW GLOBAL VARIABLES WHERE Variable_name IN
('innodb_buffer_pool_size','max_connections','tmp_table_size',
 'max_heap_table_size','temptable_max_ram','temptable_max_mmap');
SHOW GLOBAL STATUS WHERE Variable_name IN
('Threads_connected','Threads_running','Max_used_connections');

Nicht unterstützte Variablen werden in den Ergebnissen nicht angezeigt. Überprüfen Sie die beabsichtigten Einstellungen, anstatt anzunehmen, dass die neue Datei Vorrang hat. Falls der Start aufgrund Ihrer Änderung fehlschlägt, stellen Sie die gespeicherte Konfiguration wieder her oder entfernen Sie nur die neue Überschreibung und starten Sie das System neu. Bewahren Sie die Fehlerdetails zur Diagnose auf.

8. Erfolg unter repräsentativer Last definieren

free -h
vmstat 1
cat /proc/pressure/memory

Vergleichen Sie den gleichen Datenverkehr und die geplanten Jobs vor und nach den Änderungen. Verfolgen Sie neue OOM-Ereignisse, Datenbankneustarts, verfügbaren Speicher, Verbindungsabbrüche, Swap-Aktivität und Abfragelatenz. vmstatKontinuierliches Swap-In/Swap-Out sollte untersucht werden. Das Debian-Handbuch zu vmstat erklärt, dass der erste Bericht die durchschnittliche Aktivität seit dem Systemstart angibt; verwenden Sie nachfolgende Berichte für aktuelle Werte.

Die PSI-Referenz des Kernels beschreibt Druckstillstandsmessungen. Eine erhöhte Speicherstillstandszeit kann Probleme aufdecken, noch bevor es zu einem weiteren Systemabsturz kommt. Ein System, das zehn Minuten im Leerlauf übersteht, bedeutet nicht, dass die nächste Datensicherung oder der nächste Datenverkehrsanstieg sicher ist.

Missverständnisse, die das Problem verschlimmern können

Das Handbuch zur systemd-Ressourcenverwaltung von Debian erklärt, dass dies MemoryMaxdie Behandlung von Speichermangel innerhalb einer Unit auslösen kann. Entfernen Sie Provider- oder Containerlimits nicht unbedacht. Die Anwendung benötigt ein Speicherbudget, das diesen Limits entspricht, oder die Limits müssen autorisiert werden.

Es gibt keine verifizierte Mindestgröße für einen VPS, die die Ausführung dieser speziellen Arbeitslast garantiert. Wenn für einen sinnvollen Durchsatz kontinuierliches Swapping erforderlich ist, geplante Jobs weiterhin zu Prozessabbrüchen führen oder kleinere Caches die Latenz inakzeptabel machen, sollten Sie die Konfiguration nicht länger als Ersatz für Kapazität betrachten. Erweitern Sie den Arbeitsspeicher, reduzieren Sie die gleichzeitige Nutzung von Anwendungen oder verlagern Sie die Datenbank auf einen separaten Dienst.