Rulați Debian 12 pe un VPS cu RAM redusă fără blocări OOM și dezactivați MySQL

Un VPS cu memorie redusă poate rula Debian 12 și o bază de date, dar stabilitatea depinde de întreaga sarcină de lucru - nu doar de memoria cache configurată a MySQL. Când memoria disponibilă se epuizează, Linux poate invoca killer-ul de memorie insuficientă (OOM), care termină un proces pentru a proteja restul sistemului. Dacă acel proces este baza de date, simptomul poate arăta ca o prăbușire aleatorie. Scopul practic este de a preveni presiunea susținută asupra memoriei și de a confirma ce a omorât de fapt kernelul; nicio setare de optimizare nu poate garanta că evenimentele OOM nu vor avea loc niciodată.

Debian 12 rulează MySQL sau MariaDB?

Verificați serverul înainte de a-i modifica configurația. Debian 12 (Bookworm) folosește MariaDB ca default-mysql-serverpachet implicit; Oracle MySQL este o cale de instalare separată. Informațiile despre pachetul Debian listează MariaDB ca dependență de server a metapachetului respectiv. Executați:

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

Folosiți instrucțiunile MariaDB de mai jos numai dacă serviciul instalat este MariaDB. Oracle MySQL folosește în multe cazuri nume de opțiuni care arată compatibil, dar machetele pachetelor, numele serviciilor, variabilele disponibile și valorile implicite pot diferi. Consultați manualul pentru versiunea exactă de MySQL instalată.

Referințe principale: pachetul default-mysql-server din Debian Bookworm și manualul de utilizare a memoriei MySQL 8.0 .

Cum poți spune dacă OOM a distrus baza de date?

Mai întâi, distingeți o întrerupere a sistemului OOM de o eroare a bazei de date, o repornire a serviciului, o repornire sau o problemă a discului. Pe Debian, journalctlcitește jurnalul systemd. Căutați în jurnalul de bootare curent și inspectați jurnalul de service al 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

Dacă jurnalul kernelului denumește mariadbdsau mysqldapare după un mesaj OOM, aveți dovezi ale unei întreruperi de memorie. Dacă nu există nicio intrare potrivită, verificați jurnalul de erori al serviciului și istoricul de repornire sau monitorizare al furnizorului. Jurnalele pot fi indisponibile după o repornire dacă jurnalizarea nu este persistentă, iar un furnizor VPS gestionat poate expune doar o parte din diagnosticele gazdei.

Capturați o linie de bază în timp ce serverul are trafic reprezentativ, nu doar în timp ce este inactiv:

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

În vmstat, observați coloanele siși sopentru activități susținute de swap-in și swap-out. O alocare swap diferită de zero în sine nu reprezintă o problemă; swap-ul continuu împreună cu timpi de răspuns lenți indică presiune asupra memoriei. Linux documentează gestionarea OOM ca răspuns de ultimă instanță atunci când memoria nu poate fi recuperată suficient. Consultați conceptele de gestionare a memoriei din kernelul Linux și manualul journalctl al Debian .

Ce ar trebui să măsori înainte de reglare?

Înregistrați memoria RAM totală, utilizarea curentă și maximă a spamului swap, cele mai mari procese rezidente, conexiunile la baza de date și maximul normal al aplicației web. Baza de date împarte memoria cu Debian, serverul web, operatorii aplicației, agenții de monitorizare și memoria cache a sistemului de fișiere. Un VPS poate avea, de asemenea, o limită de memorie pentru container sau cgroup mai mică decât memoria RAM fizică a gazdei; dimensionați memoria cache a bazei de date la limita de memorie vizibilă serviciului, nu la un total mai mare al gazdei.

Pentru MariaDB, verificați setările curente legate de memorie și vârful de conexiune:

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

Pool-ul de buffere InnoDB stochează în cache paginile tabelului și ale indexului. Limitele de conexiune și bufferele de interogare pot crește cererea de memorie pe măsură ce crește munca concurentă. Evitați înmulțirea fiecărui buffer per conexiune cu max_connectionsca și cum fiecare buffer ar fi întotdeauna alocat complet, dar tratați un plafon de conexiuni foarte ridicat ca un risc în cazul burstelor. Ghidul de memorie MariaDB recomandă dimensionarea împreună a cache-urilor globale, a bufferelor per conexiune și a setărilor motorului și apelează în mod specific pool-urile de conexiuni ale aplicațiilor. Citiți ghidul de alocare a memoriei MariaDB și ghidul său pentru gestionarea unui număr prea mare de conexiuni .

Cum dimensionezi corect MariaDB pe un VPS mic?

Faceți o modificare pe rând, păstrați o copie a configurației originale și testați în timpul unei ferestre de mentenanță dacă o repornire ar afecta utilizatorii. Configurația MariaDB inclusă în pachetul Debian include de obicei fișiere sub /etc/mysql/mariadb.conf.d/; verificați directoarele active de includere din instalare înainte de editare. Un fișier drop-in mic este mai ușor de eliminat decât înlocuirea fișierului principal al furnizorului:

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

Pentru un VPS partajat cu aproximativ 1 GiB de RAM, următorul exemplu este doar un început precaut - nu un profil universal sigur. Reduceți sau creșteți valorile în funcție de memoria maximă măsurată, dimensiunea bazei de date, volumul de lucru și memoria RAM rămasă pentru sistemul de operare și aplicație:

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

MariaDB citește setările din fișierele de opțiuni la pornire; verificați numele secțiunilor acceptate și valorile efective ale versiunii dvs. Dacă acest fișier nu se încarcă, eliminați drop-in-ul și verificați jurnalul. Repornirea bazei de date întrerupe conexiunile existente, așa că programați-o corespunzător:

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;"

Evaluați rezultatul atât în ​​funcție de stabilitate, cât și de calitatea serviciilor. Un pool de buffere mai mic poate reduce accesările din cache și poate crește numărul de citiri pe disc. O reducere max_connectionsprea mare poate produce în schimb erori de tip „Prea multe conexiuni”. Comparați Max_used_connectionscu limita configurată și revizuiți dimensiunile pool-ului de aplicații înainte de a modifica din nou limita respectivă. Dacă baza de date este în continuare întreruptă în timpul traficului de vârf normal sau dacă timpul de răspuns se degradează din cauza schimbării susținute a discului, treceți la un nivel de RAM mai mare sau separați baza de date de aplicație.

Poate swap-ul să prevină o prăbușire a OOM?

Swap-ul oferă Linux-ului un spațiu mai lent pentru a muta unele pagini de memorie și poate absorbi un vârf scurt. Nu adaugă RAM rapid, nu remediază o scurgere și nu face un VPS subdimensionat potrivit pentru o sarcină de lucru susținută. Swap-urile intense pot face ca atât baza de date, cât și aplicația să nu răspundă. Verificați dacă furnizorul dvs. acceptă fișiere swap și dacă VPS-ul are suficient spațiu pe disc înainte de a crea unul.

Dacă este acceptat, un fișier swap de 1 GiB poate fi creat după cum urmează. Ajustați dimensiunea conform instrucțiunilor furnizorului și discului disponibil și verificați rezultatul fiecărei comenzi:

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

Pentru a o activa după repornire, adăugați această intrare /etc/fstabdupă ce verificați dacă nu există deja o intrare echivalentă:

/swapfile none swap sw 0 0

Apoi validați fișierul cu sudo findmnt --verify --verboseși confirmați că apare în swapon --show. Dacă fallocatenu este acceptat de sistemul de fișiere sau furnizorul blochează swap-ul, opriți-l și utilizați procedura acceptată de furnizor. Nu dezactivați OOM killer și nu atribuiți un scor de protecție OOM extrem pentru MySQL: acest lucru nu creează memorie și poate pune restul unui VPS mic într-un risc mai mare.

De unde știi că schimbările au funcționat?

Observați VPS-ul pe parcursul a cel puțin o perioadă normală de activitate. Un rezultat util are mai multe semne:

• Nu există noi intrări OOM-kill pentru kernel în timpul sarcinii de lucru care a declanșat anterior incidentul.
• MariaDB rămâne activă și numărul de reporniri nu crește neașteptat.
• vmstat 1nu prezintă schimbări continue de semnal în trafic obișnuit.
• Aplicația rămâne receptivă, iar vârfurile de conexiune la baza de date rămân sub noul plafon, fără erori de conexiune.
• Copiile de rezervă sunt finalizate, iar interogările bazei de date continuă să respecte latența acceptabilă a aplicației.

Nu folosiți „serviciul pornește” ca singur test de succes. O setare care menține MariaDB activă, dar împinge sistemul într-o stare constantă de schimbare a datelor (swapping) nu a rezolvat problema capacității subiacente. De asemenea, o zi liniștită nu validează un import lunar, o copie de rezervă, un vârf de trafic sau o lucrare batch care nu a fost încă executată.

Când nu mai este tuningul soluția potrivită?

Alegeți un VPS mai mare sau mutați sarcinile de lucru separat atunci când memoria rămâne suprasolicitată după ajustări rezonabile ale memoriei cache și ale concurenței, activitatea de swap este susținută, latența interogărilor devine inacceptabilă sau aplicația atinge în mod repetat noua limită de conexiune. Dimensiunea bazei de date contează și ea: un pool de buffere prea mic poate evita un vârf de memorie, transformând în același timp I/O pe disc noul blocaj. Dacă aplicația și baza de date au vârfuri ascuțite, dar previzibile, stabiliți mai întâi dacă aplicația deschide conexiuni în exces sau rulează simultan joburi care necesită multă memorie.

Pe Oracle MySQL, în loc de MariaDB-ul implicit al Debian, confirmați numele serviciului, calea fișierului de opțiuni și variabilele de memorie în funcție de manualul versional al serverului respectiv înainte de a aplica aceste exemple. Pe oricare dintre motoare, păstrați copiile de rezervă testate și modificați câte o variabilă pe rând. Rezultatul fiabil nu este o promisiune că Linux nu va invoca niciodată gestionarea OOM; este o dovadă că VPS-ul are suficient spațiu pentru volumul său real de lucru maxim și că MySQL sau MariaDB nu mai sunt victima recurentă.

Referințe principale suplimentare: Ghidul de depanare la pornire al MariaDB , care menționează că serverul are nevoie și de memorie pentru alte motoare, buffere per conexiune și sistemul de operare, precum și Manualul de referință MySQL 8.0 .