Debian 12 su un VPS con poca RAM: come ridurre i crash di MySQL dovuti a errori di memoria insufficiente (OOM).

È possibile ridurre il rischio che il killer OOM arresti MySQL su un VPS Debian 12 con poca RAM identificando la causa, allocando memoria a tutti i servizi, limitando la concorrenza del database e fornendo swap laddove il VPS lo consenta. Un buffer pool InnoDB più piccolo da solo non è una soluzione completa. Né lo swap né un'impostazione di protezione OOM garantiscono che un carico di lavoro sovradimensionato continui a funzionare.

Questa guida è stata redatta il 9 ottobre 2026 utilizzando Debian 12 “bookworm”, Linux 6.1 e la documentazione di Oracle MySQL 8.0/8.4. Le impostazioni riportate di seguito sono da intendersi come punti di partenza esemplificativi, non come risultati di benchmark o configurazioni universali. Eseguire un backup del database e della configurazione prima di apportare modifiche e pianificare i riavvii del database quando i tempi di inattività sono accettabili.

1. Identifica il server prima di copiare le impostazioni di MySQL

Verificato: il pacchetto default-mysql-server di Debian 12 dipende da MariaDB. Un VPS descritto come dotato di "MySQL" potrebbe in realtà utilizzare MariaDB, mentre un altro potrebbe avere Oracle MySQL proveniente da un repository o container separato.

mysql --version
systemctl status mysql mariadb

Il primo comando identifica il client, non necessariamente il server in esecuzione. Connettiti utilizzando il tuo account di amministratore del database ed esegui:

SELECT VERSION(), @@version_comment;

Utilizza il tuo metodo di autenticazione esistente; le installazioni di MariaDB su Debian potrebbero consentire l'amministrazione locale con sudo mysql. Annota la versione del server e il nome effettivo del servizio. I comandi di servizio successivi utilizzano mysql.service; sostituisci mariadb.servicequando necessario. Non aggiungere variabili specifiche di Oracle alla configurazione di MariaDB.

2. Confermare che lo spegnimento è stato causato da un evento OOM (Out Of Memory).

Errore comune: ogni riavvio inspiegabile del database è un'interruzione per esaurimento della memoria (OOM kill). Anche errori di autenticazione, esaurimento del disco, configurazione non valida, arresti anomali e riavvii da parte dell'amministratore possono interrompere il servizio.

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

Analizza i messaggi del kernel relativi al momento dell'incidente, individuando eventuali errori di memoria insufficiente e il processo terminato, e confrontali con il log di servizio. Se il pacchetto in uso scrive i dati in un file anziché nel journal, controlla anche il log degli errori del database. Se l'incidente si è verificato prima di un riavvio, esamina l'avvio precedente, journalctl -k -b -1se sono disponibili i log storici. La mancanza di log storici non consente di confermare la causa dell'errore.

Un gestore dello spazio utente può anche terminare i carichi di lavoro. Il manuale di systemd-oomd di Debian descrive l'intervento basato sulla pressione della memoria prima di un evento OOM del kernel. Verifica se è installato e attivo, invece di dare per scontato che ogni VPS Debian lo utilizzi.

Verifica anche i limiti di systemd:

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

Su un sistema cgroup v2, utilizzare il percorso ControlGroup segnalato per leggere memory.events, memory.max, e memory.swap.maxsotto /sys/fs/cgroup. Controllare anche i cgroup padre. La documentazione di Linux cgroup v2 spiega questi contatori e limiti. Un cgroup può esaurire la memoria consentita anche se l'host ha capacità disponibile. Un oom_killcontatore registra le terminazioni, ma deve essere interpretato con limiti e log per stabilire la causa.

3. Misurare l'intero VPS, non solo il buffer pool.

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

Raccogli osservazioni durante il normale traffico e i processi associati ai guasti. In free, concentrati sulla memoria disponibile, non solo sulla colonna libera. Il manuale gratuito di Debian descrive la memoria disponibile come una stima di quella che può essere utilizzata senza ricorrere allo swapping. I valori RSS nell'elenco dei processi sono in KiB; la loro aggiunta può conteggiare due volte la memoria condivisa.

Verificato: MySQL alloca memoria oltre il buffer pool di InnoDB, includendo allocazioni relative alla connessione e alle query. La documentazione di riferimento sull'utilizzo della memoria di MySQL descrive questi componenti. Considera una formula basata sui buffer configurati come una stima di pianificazione, non come un limite superiore preciso.

Azione: Riservare capacità per il kernel, i processi web, il monitoraggio, i backup e le operazioni temporanee sul database. Il consiglio comune di dedicare la maggior parte della RAM a InnoDB non è adatto, senza opportune modifiche, su un VPS condiviso. Se i processi PHP o un processo di compilazione consumano la capacità disponibile, ottimizzare o spostare tale carico di lavoro anziché ridurre ripetutamente le dimensioni di MySQL.

4. Aggiungere lo swap come buffer, non come RAM sostitutiva.

Dipendente dal contesto: lo swap può assorbire temporaneamente la pressione sulla memoria anonima, ma un utilizzo prolungato dello swap può rallentare eccessivamente le query. Un VPS basato su container potrebbe limitare lo swap e un servizio MemorySwapMaxpotrebbe impedirne l'uso anche quando l'host dispone di swap.

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

Se la partizione di swap non è presente, il provider lo consente e si dispone di spazio su disco sufficiente, il seguente comando crea un file di swap da 1 GiB su un filesystem locale appropriato, come ext4. Non eseguirlo se /swapfile esiste già. Verificare prima i requisiti specifici del filesystem; Btrfs richiede una configurazione del file di swap senza copia su scrittura.

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

Solo dopo che l'attivazione è andata a buon fine, aggiungi questa voce una sola volta a /etc/fstab:

/swapfile none swap sw 0 0

Il manuale di Debian swapon documenta i vincoli relativi al file di swap. Se l'attivazione viene negata dall'ambiente VPS, chiedere al provider informazioni sullo swap supportato o aumentare la memoria del piano; non rendere persistente una configurazione non riuscita.

Non copiare la modifica "imposta swappiness a zero" come protezione da OOM (Out Of Memory). La documentazione della macchina virtuale del kernel definisce swappiness come una preferenza relativa al costo di recupero della memoria. Non crea memoria né impone un limite di memoria al database. Lasciala inizialmente invariata e monitora il comportamento.

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 una velocità di elaborazione 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.