Debian 12 on a Low-RAM VPS: How to Reduce MySQL OOM Crashes

You can reduce the risk of the OOM killer stopping MySQL on a low-RAM Debian 12 VPS by confirming the cause, budgeting memory across all services, limiting database concurrency, and providing swap where the VPS permits it. A smaller InnoDB buffer pool alone is not a complete fix. Neither swap nor an OOM-protection setting guarantees that an oversized workload will keep running.

This guide was researched on October 9, 2026, using Debian 12 “bookworm,” Linux 6.1, and Oracle MySQL 8.0/8.4 documentation. The settings below are illustrative starting points, not benchmark results or a universal configuration. Back up the database and configuration before changes, and schedule database restarts when downtime is acceptable.

1. Identify the server before copying MySQL settings

Verified: Debian 12’s default-mysql-server package depends on MariaDB. A VPS described as running “MySQL” may actually run MariaDB, while another may have Oracle MySQL from a separate repository or container.

mysql --version
systemctl status mysql mariadb

The first command identifies the client, not conclusively the running server. Connect using your database administrator account and run:

SELECT VERSION(), @@version_comment;

Use your existing authentication method; Debian MariaDB installations may allow local administration with sudo mysql. Record the server version and real service name. Subsequent service commands use mysql.service; substitute mariadb.service when appropriate. Do not add Oracle-only variables to MariaDB configuration.

2. Confirm that the shutdown was an OOM event

Common misunderstanding: Every unexplained database restart is an OOM kill. Authentication errors, disk exhaustion, invalid configuration, crashes, and administrator restarts can also interrupt service.

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

Look around the incident time for kernel messages identifying an out-of-memory condition and the killed process, then correlate those messages with the service log. Also inspect the database error log if your package writes it to a file rather than the journal. If the incident happened before a reboot, inspect the previous boot with journalctl -k -b -1 when retained logs are available. Missing historical logs leave the cause unconfirmed.

A userspace manager can also terminate workloads. Debian’s systemd-oomd manual describes intervention based on memory pressure before a kernel OOM event. Check whether it is installed and active rather than assuming every Debian VPS uses it.

Inspect systemd limits as well:

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

On a cgroup v2 system, use the reported ControlGroup path to read memory.events, memory.max, and memory.swap.max under /sys/fs/cgroup. Check parent cgroups too. The Linux cgroup v2 documentation explains these counters and limits. A cgroup can run out of its allowed memory even while the host has capacity. An oom_kill counter records kills but must be interpreted with limits and logs to establish the cause.

3. Measure the whole VPS, not just the buffer pool

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

Collect observations during normal traffic and the jobs associated with failures. In free, focus on available memory, not merely the free column. Debian’s free manual describes available memory as an estimate of what can be used without swapping. RSS values in the process listing are in KiB; adding them can double-count shared memory.

Verified: MySQL allocates memory beyond InnoDB’s buffer pool, including connection and query-related allocations. The MySQL memory-use reference documents these components. Treat a formula based on configured buffers as a planning estimate, not a precise upper bound.

Action: Reserve capacity for the kernel, web workers, monitoring, backups, and transient database work. The familiar advice to devote most RAM to InnoDB is unsuitable without adjustment on a shared VPS. If PHP workers or a build job consume the available headroom, tune or move that workload instead of repeatedly shrinking MySQL.

4. Add swap as a buffer, not as replacement RAM

Context-dependent: Swap can absorb some temporary anonymous-memory pressure, but sustained swapping can make queries too slow. A container-based VPS may restrict swap, and a service’s MemorySwapMax can prevent its use even when the host has swap.

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

If swap is absent, the provider permits it, and you have adequate disk headroom, the following creates a 1 GiB swap file on a suitable local filesystem such as ext4. Do not run it if /swapfile already exists. Review filesystem-specific requirements first; Btrfs needs a suitable no-copy-on-write swap-file setup.

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

Only after activation succeeds, add this entry once to /etc/fstab:

/swapfile none swap sw 0 0

The Debian swapon manual documents swap-file constraints. If activation is denied by the VPS environment, ask the provider about supported swap or increase the plan’s memory; do not persist a failed setup.

Do not copy a “set swappiness to zero” tweak as OOM protection. The kernel VM documentation defines swappiness as a reclamation-cost preference. It does not create memory or impose a database memory limit. Leave it unchanged initially and measure behavior.

5. Stabilire una base di base modesta per il database

A titolo esemplificativo, si consideri un VPS da 1 GiB con un carico di lavoro InnoDB ridotto e alcuni worker applicativi. I seguenti valori rappresentano un'ipotesi da valutare, non una prova definitiva della compatibilità di questo carico di lavoro:

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

Inserisci le opzioni del server in un file di configurazione effettivamente incluso nell'installazione. Un pacchetto Oracle MySQL potrebbe includere /etc/mysql/mysql.conf.d/; Debian MariaDB utilizza comunemente /etc/mysql/mariadb.conf.d/. Verifica le direttive di inclusione esistenti e conservane una copia di backup. La documentazione di MySQL sui file di opzioni spiega i gruppi di opzioni del server e la gestione dei file.

Un buffer pool da 128 MiB limita la cache, non la memoria totale del database. Un limite di 20 connessioni potrebbe essere troppo restrittivo se diverse istanze dell'applicazione mantengono ciascuna un proprio pool. Al contrario, 20 query complesse simultanee potrebbero comunque sovraccaricare il VPS. Mantieni il numero totale di connessioni nel pool dell'applicazione al di sotto del limite previsto per il server, lasciando spazio per l'accesso amministrativo, e monitora le connessioni rifiutate.

Le variabili comuni menzionate sopra compaiono anche nel riferimento alle variabili di sistema di MariaDB , ma il comportamento delle tabelle temporanee varia a seconda del prodotto e della versione. Evitate di aumentare i buffer globali di ordinamento, join o lettura come soluzione generica per migliorare le prestazioni su una macchina con risorse limitate.

6. Gestire contemporaneamente tabelle temporanee e concorrenza.

Un equivoco comune: si pensa che l'impostazione tmp_table_size=16Mlimiti la memoria di tutte le query a 16 MiB. Non è così. Sessioni multiple, tabelle temporanee multiple e altre allocazioni di esecuzione possono coesistere.

Per Oracle MySQL 8.4 , un ulteriore punto di partenza illustrativo è il seguente:

temptable_max_ram=64M
temptable_max_mmap=0

Aggiungi questi parametri al [mysqld]gruppo esistente solo dopo aver verificato il supporto del prodotto. Regolano la soglia di RAM condivisa del motore TempTable e l'utilizzo dei file temporanei mappati in memoria. Non limitano l'intero processo mysqld né tutte le allocazioni locali dei thread. Soglie inferiori possono spostare più operazioni su disco.

La documentazione di MySQL 8.4 sulle tabelle temporanee spiega questi limiti. MySQL 8.0 presenta un comportamento dipendente dalla versione: temptable_max_mmapintrodotto nella 8.0.23, è tmp_table_sizediventato un limite specifico per ogni TempTable nella 8.0.28. Consultare la documentazione di riferimento di MySQL 8.0 prima di applicare le stesse impostazioni. Non copiare queste opzioni specifiche di Oracle in MariaDB.

Azione: Limitare le query di report sovrapposte, i processi in background e le operazioni di backup o importazione. Rivedere i piani di query e gli indici quando una particolare operazione genera un carico eccessivo. Spostare le operazioni di grandi dimensioni al di fuori dei picchi di traffico può essere d'aiuto; se la normale domanda simultanea continua a superare la capacità, il passo successivo appropriato è aggiungere RAM o separare il database.

7. Convalida le modifiche e riavvia deliberatamente

Per le versioni di Oracle MySQL che supportano questa opzione, verificare la configurazione prima del riavvio:

sudo mysqld --validate-config

Se il servizio non utilizza il rilevamento automatico della configurazione predefinita, utilizzare lo stesso percorso del file di configurazione predefinito e gli stessi argomenti di avvio pertinenti. La documentazione di riferimento sulla convalida di MySQL specifica che la convalida non inizializza tutti i sottosistemi. Superarla non equivale a un test di capacità di carico. Non dare per scontato che MariaDB supporti questa opzione di Oracle.

Riavvia il servizio effettivo durante l'intervallo di tempo pianificato, quindi controlla l'avvio e verifica i valori effettivi:

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');

Le variabili non supportate non verranno visualizzate nei risultati. Verifica le impostazioni desiderate anziché presumere che il nuovo file abbia la precedenza. Se l'avvio non riesce a causa della modifica, ripristina la configurazione salvata o rimuovi solo la nuova sovrascrittura, quindi riavvia il sistema. Conserva i dettagli dell'errore per la diagnosi.

8. Definire il successo in condizioni di carico rappresentativo

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

Confronta lo stesso traffico e gli stessi processi pianificati prima e dopo le modifiche. Tieni traccia dei nuovi eventi OOM, dei riavvii del database, della memoria disponibile, dei rifiuti di connessione, dell'attività di swap e della latenza delle query. In vmstat, il continuo swap-in/swap-out merita un'indagine. Il manuale di Debian vmstat spiega che il primo report calcola la media dell'attività dall'avvio; usa i report successivi per i tassi attuali.

Il riferimento PSI del kernel descrive le misurazioni del tempo di stallo della pressione. Un aumento del tempo di stallo della memoria può rivelare problemi anche prima di un altro arresto anomalo. Un sistema inattivo che sopravvive per dieci minuti non garantisce che il backup successivo o il picco di traffico siano sicuri.

Idee sbagliate che possono peggiorare il problema

Il manuale di controllo delle risorse systemd di Debian spiega che MemoryMaxè possibile richiamare la gestione OOM all'interno di un'unità. Non rimuovere i limiti del provider o del container alla cieca. L'applicazione necessita di un budget di memoria compatibile con tali limiti, oppure i limiti richiedono una modifica autorizzata della capacità.

Non esiste una dimensione minima verificata per VPS che garantisca l'esecuzione di questo particolare carico di lavoro. Se per ottenere un throughput utile è necessario un continuo scambio di dati, se i processi pianificati continuano a essere interrotti o se cache di dimensioni ridotte rendono la latenza inaccettabile, smettete di considerare la configurazione come un sostituto della capacità. Aumentate la RAM, riducete la concorrenza delle applicazioni o spostate il database su un servizio separato.