Debian 12 na serwerze VPS z małą ilością pamięci RAM: Jak ograniczyć awarie MySQL spowodowane brakiem pamięci (OOM)

Ryzyko zatrzymania MySQL przez OOM Killera na serwerze VPS Debian 12 z małą ilością pamięci RAM można zmniejszyć, potwierdzając przyczynę problemu, budżetując pamięć dla wszystkich usług, ograniczając współbieżność bazy danych i udostępniając przestrzeń wymiany tam, gdzie pozwala na to serwer VPS. Sama mniejsza pula buforów InnoDB nie jest rozwiązaniem problemu. Ani przestrzeń wymiany, ani ustawienie ochrony przed OOM nie gwarantują, że przeciążenie będzie nadal działać.

Niniejszy przewodnik został opracowany 9 października 2026 roku z wykorzystaniem dokumentacji Debiana 12 „bookworm”, Linuksa 6.1 oraz Oracle MySQL 8.0/8.4. Poniższe ustawienia stanowią przykładowy punkt wyjścia, a nie wyniki testów porównawczych ani uniwersalną konfigurację. Przed wprowadzeniem zmian należy wykonać kopię zapasową bazy danych i konfiguracji oraz zaplanować ponowne uruchomienie bazy danych, gdy przestój jest akceptowalny.

1. Zidentyfikuj serwer przed skopiowaniem ustawień MySQL

Zweryfikowano: Pakiet default-mysql-server systemu Debian 12 zależy od MariaDB. Serwer VPS opisany jako „MySQL” może w rzeczywistości obsługiwać MariaDB, podczas gdy inny może mieć Oracle MySQL z oddzielnego repozytorium lub kontenera.

mysql --version
systemctl status mysql mariadb

Pierwsze polecenie identyfikuje klienta, ale nie identyfikuje jednoznacznie działającego serwera. Połącz się, używając konta administratora bazy danych i uruchom:

SELECT VERSION(), @@version_comment;

Użyj istniejącej metody uwierzytelniania; instalacje Debian MariaDB mogą zezwalać na administrację lokalną za pomocą sudo mysql. Zapisz wersję serwera i rzeczywistą nazwę usługi. W kolejnych poleceniach usługi użyj mysql.service; mariadb.servicew razie potrzeby. Nie dodawaj zmiennych przeznaczonych tylko dla Oracle do konfiguracji MariaDB.

2. Potwierdź, że wyłączenie było zdarzeniem OOM

Częste nieporozumienie: Każdy niewyjaśniony restart bazy danych to awaria pamięci (OOM). Błędy uwierzytelniania, wyczerpanie dysku, nieprawidłowa konfiguracja, awarie i restarty administratora również mogą zakłócić działanie usługi.

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

Poszukaj w czasie wystąpienia zdarzenia komunikatów jądra identyfikujących stan braku pamięci i zatrzymany proces, a następnie porównaj te komunikaty z dziennikiem usługi. Sprawdź również dziennik błędów bazy danych, jeśli pakiet zapisuje je do pliku, a nie do dziennika. Jeśli zdarzenie wystąpiło przed ponownym uruchomieniem, sprawdź poprzedni rozruch i journalctl -k -b -1dostępność zachowanych dzienników. Brak historycznych dzienników pozostawia przyczynę niepotwierdzoną.

Menedżer przestrzeni użytkownika może również kończyć obciążenia. Podręcznik systemu systemd-oomd Debiana opisuje interwencję opartą na obciążeniu pamięci przed zdarzeniem braku pamięci (OOM) jądra. Sprawdź, czy jest zainstalowany i aktywny, zamiast zakładać, że każdy serwer VPS z Debianem go używa.

Sprawdź również limity systemd:

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

W systemie cgroup v2 użyj zgłoszonej ścieżki ControlGroup, aby odczytać memory.events, memory.maxi memory.swap.maxponiżej /sys/fs/cgroup. Sprawdź również nadrzędne cgroup. Dokumentacja Linux cgroup v2 wyjaśnia te liczniki i limity. cgroup może wyczerpać dozwoloną pamięć, nawet gdy host ma wystarczającą pojemność. Licznik oom_killrejestruje zamykanie, ale musi być interpretowany z limitami i logami, aby ustalić przyczynę.

3. Zmierz cały VPS, a nie tylko pulę buforów

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

Zbieraj obserwacje podczas normalnego ruchu i zadań związanych z awariami. W [brakuje kontekstu - kontekstu - kontekstu] skup się na dostępnej pamięci, a nie tylko na wolnej kolumnie. W podręcznikufree Debiana dostępna pamięć jest opisana jako szacunkowa ilość pamięci, która może zostać wykorzystana bez wymiany. Wartości RSS w liście procesów są wyrażone w KiB; ich dodanie może spowodować podwójne naliczenie pamięci współdzielonej.

Zweryfikowano: MySQL alokuje pamięć poza pulą buforów InnoDB, w tym alokacje związane z połączeniami i zapytaniami. Dokumentacja MySQL dotycząca wykorzystania pamięci dokumentuje te komponenty. Formułę opartą na skonfigurowanych buforach należy traktować jako oszacowanie planistyczne, a nie jako precyzyjną górną granicę.

Działanie: Zarezerwuj pojemność dla jądra, webworkerów, monitorowania, kopii zapasowych i przejściowej pracy bazy danych. Znana rada, aby przeznaczyć większość pamięci RAM na InnoDB, nie sprawdza się bez dostosowania na współdzielonym serwerze VPS. Jeśli workworkery PHP lub zadanie kompilacji zużywają dostępny zapas mocy obliczeniowej, dostosuj lub przenieś to obciążenie zamiast wielokrotnie zmniejszać wydajność MySQL.

4. Dodaj pamięć wymiany jako bufor, a nie jako zamienną pamięć RAM

Zależne od kontekstu: Swap może absorbować chwilowe obciążenie pamięci anonimowej, ale ciągłe swapowanie może powodować, że zapytania będą zbyt wolne. Serwer VPS oparty na kontenerach może ograniczać swap, a usługa MemorySwapMaxmoże uniemożliwić jego użycie, nawet gdy host ma swap.

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

Jeśli swap jest nieobecny, dostawca na to pozwala i masz wystarczającą ilość wolnego miejsca na dysku, poniższy kod tworzy plik wymiany o rozmiarze 1 GiB w odpowiednim lokalnym systemie plików, takim jak ext4. Nie uruchamiaj go, jeśli plik /swapfile już istnieje. Najpierw sprawdź wymagania specyficzne dla danego systemu plików; Btrfs wymaga odpowiedniej konfiguracji pliku wymiany bez kopiowania przy zapisie.

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

Dopiero po pomyślnym zakończeniu aktywacji dodaj ten wpis jeden raz do /etc/fstab:

/swapfile none swap sw 0 0

W podręczniku Debiana dotyczącym swapu opisano ograniczenia dotyczące pliku wymiany. Jeśli aktywacja jest blokowana przez środowisko VPS, należy zapytać dostawcę o obsługiwany plik wymiany lub zwiększyć pamięć planu; nie należy utrwalać nieudanej konfiguracji.

Nie kopiuj poprawki „ustaw swappiness na zero” jako zabezpieczenia przed brakiem pamięci (OOM). Dokumentacja maszyny wirtualnej jądra definiuje swappiness jako preferencję kosztu odzyskiwania. Nie tworzy ona pamięci ani nie nakłada limitu pamięci bazy danych. Pozostaw ją początkowo niezmienioną i zmierz zachowanie.

5. Ustal skromną bazę danych bazową

Dla przykładu rozważmy serwer VPS o pojemności 1 GiB z niewielkim obciążeniem InnoDB i kilkoma pracownikami aplikacji. Poniższe wartości stanowią propozycję do oceny, a nie dowód na to, że to obciążenie jest odpowiednie:

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

Umieść opcje serwera w pliku konfiguracyjnym faktycznie dołączonym podczas instalacji. Pakiet Oracle MySQL może zawierać /etc/mysql/mysql.conf.d/; Debian MariaDB często używa . Zweryfikuj istniejące dyrektywy include i zachowaj kopię zapasową. Dokumentacja pliku opcji/etc/mysql/mariadb.conf.d/ MySQL wyjaśnia grupy opcji serwera i obsługę plików.

Pula buforów o pojemności 128 MiB ogranicza pamięć podręczną, a nie całkowitą pamięć bazy danych. Limit połączeń wynoszący 20 może być zbyt restrykcyjny, jeśli kilka instancji aplikacji utrzymuje pulę. Z drugiej strony, 20 jednoczesnych, intensywnych zapytań może nadal przeciążać serwer VPS. Utrzymuj pulę aplikacji poniżej zamierzonego limitu serwera, z zachowaniem możliwości dostępu administracyjnego, i obserwuj odrzucone połączenia.

Wymienione powyżej zmienne wspólne pojawiają się również w dokumentacji zmiennych systemowych MariaDB , ale zachowanie tabel tymczasowych różni się w zależności od produktu i wersji. Unikaj zwiększania globalnych buforów sortowania, dołączania i odczytu jako ogólnej poprawki wydajności na ograniczonej maszynie.

6. Kontroluj tabele tymczasowe i współbieżność

Powszechne nieporozumienie: Ustawienie tmp_table_size=16Mlimitu pamięci zapytań na poziomie 16 MiB nie powoduje tego. Wiele sesji, wiele tabel tymczasowych i inne alokacje wykonawcze mogą współistnieć.

W przypadku Oracle MySQL 8.4 dodatkowym ilustrującym punktem wyjścia jest:

temptable_max_ram=64M
temptable_max_mmap=0

Dodaj je do istniejącej [mysqld]grupy dopiero po potwierdzeniu obsługi produktu. Regulują one próg współdzielonej pamięci RAM silnika TempTable i wykorzystanie plików tymczasowych mapowanych w pamięci. Nie ograniczają one całego procesu MySQL ani wszystkich alokacji lokalnych wątków. Niższe progi mogą powodować przeniesienie większej ilości zadań na dysk.

Dokumentacja tabel tymczasowych MySQL 8.4 wyjaśnia te ograniczenia. MySQL 8.0 ma zachowanie zależne od wersji: temptable_max_mmappojawił się w wersji 8.0.23 i tmp_table_sizestał się indywidualnym limitem dla tabel tymczasowych w wersji 8.0.28. Przed zastosowaniem tych samych ustawień zapoznaj się z dokumentacją MySQL 8.0 . Nie kopiuj tych opcji specyficznych dla Oracle do MariaDB.

Działanie: Ogranicz nakładające się zapytania do raportów, procesy robocze w tle oraz zadania tworzenia kopii zapasowych lub importu. Przejrzyj plany zapytań i indeksy, gdy dana operacja generuje obciążenie. Przeniesienie ponadwymiarowych zadań poza szczytowy ruch może pomóc; jeśli normalne, współbieżne zapotrzebowanie nadal przekracza przepustowość, odpowiednim kolejnym krokiem będzie dodatkowa pamięć RAM lub oddzielenie bazy danych.

7. Sprawdź zmiany i uruchom ponownie system rozmyślnie

W przypadku wersji Oracle MySQL obsługujących tę opcję należy sprawdzić konfigurację przed ponownym uruchomieniem:

sudo mysqld --validate-config

Użyj tej samej ścieżki do pliku defaults i odpowiednich argumentów startowych, co usługa, jeśli nie korzysta z wykrywania konfiguracji domyślnej. W dokumentacji walidacji MySQL zaznaczono, że walidacja nie inicjuje każdego podsystemu. Jej zaliczenie nie jest testem obciążenia i wydajności. Nie zakładaj, że MariaDB obsługuje tę opcję Oracle.

Uruchom ponownie usługę w zaplanowanym czasie, a następnie sprawdź uruchomienie i zapytaj o wartości efektywne:

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

Nieobsługiwane zmienne nie pojawią się w wynikach. Sprawdź zamierzone ustawienia, zamiast zakładać, że nowy plik ma pierwszeństwo. Jeśli uruchomienie nie powiedzie się z powodu wprowadzonej zmiany, przywróć zapisaną konfigurację lub usuń tylko nową nadpisaną konfigurację, a następnie uruchom ponownie. Zachowaj szczegóły błędu w celu diagnostyki.

8. Zdefiniuj sukces w warunkach obciążenia reprezentacyjnego

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

Porównaj ten sam ruch i zaplanowane zadania przed i po zmianach. Śledź nowe zdarzenia OOM, restarty bazy danych, dostępną pamięć, odrzucenia połączeń, aktywność wymiany i opóźnienia zapytań. W systemie vmstat, ciągłe operacje wymiany (swap-in/swap-out) wymagają analizy. Podręcznik Debian vmstat wyjaśnia, że ​​pierwszy raport uśrednia aktywność od momentu uruchomienia; kolejne raporty służą do określania bieżących wskaźników.

Referencje dotyczące PSI w jądrze opisują pomiary ciśnienia i zastoju. Wydłużenie czasu zastoju pamięci może ujawnić problem jeszcze przed kolejnym wyłączeniem. Dziesięciominutowy okres bezczynności systemu nie oznacza, że ​​kolejna kopia zapasowa lub wzrost ruchu jest bezpieczny.

Błędne przekonania, które mogą pogorszyć problem

Podręcznik systemu Debian do kontroli zasobów systemd wyjaśnia, że MemoryMax​​można wywołać obsługę braku pamięci (OOM) w jednostce. Nie należy bezmyślnie usuwać limitów dostawcy lub kontenera. Aplikacja potrzebuje budżetu pamięci, który mieści się w tych limitach, lub limity wymagają autoryzowanej zmiany pojemności.

Nie ma zweryfikowanego minimalnego rozmiaru VPS, który gwarantuje uruchomienie tego konkretnego obciążenia. Jeśli użyteczna przepustowość wymaga ciągłej wymiany, jeśli zaplanowane zadania nadal powodują zamykanie lub jeśli mniejsze pamięci podręczne powodują nieakceptowalne opóźnienia, przestań traktować konfigurację jako substytut pojemności. Zwiększ pamięć RAM, zmniejsz współbieżność aplikacji lub przenieś bazę danych do osobnej usługi.