Uruchom Debiana 12 na serwerze VPS z małą ilością pamięci RAM bez awarii pamięci masowej (OOM) powodujących awarię MySQL

Serwer VPS z małą ilością pamięci może obsługiwać system Debian 12 i bazę danych, ale stabilność zależy od całego obciążenia — nie tylko od skonfigurowanej pamięci podręcznej MySQL. Gdy dostępna pamięć się wyczerpie, Linux może wywołać program OOM (Out-of-Memory Killer), który kończy proces w celu ochrony reszty systemu. Jeśli tym procesem jest baza danych, objaw może przypominać losową awarię. Praktycznym celem jest zapobieganie długotrwałemu obciążeniu pamięci i potwierdzenie, co jądro faktycznie usunęło; żadne ustawienie dostrajające nie gwarantuje, że zdarzenia OOM nigdy nie wystąpią.

Czy Debian 12 obsługuje MySQL czy MariaDB?

Sprawdź serwer przed zmianą jego konfiguracji. Debian 12 (Bookworm) używa MariaDB jako domyślnego default-mysql-serverpakietu; Oracle MySQL to osobna ścieżka instalacji. Informacje o pakiecie Debiana wymieniają MariaDB jako zależność serwera tego metapakietu. Uruchom:

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

Poniższych instrukcji dotyczących MariaDB należy używać tylko wtedy, gdy zainstalowaną usługą jest MariaDB. Oracle MySQL w wielu przypadkach używa nazw opcji wyglądających na zgodne, ale układy pakietów, nazwy usług, dostępne zmienne i ustawienia domyślne mogą się różnić. Zapoznaj się z instrukcją obsługi, aby dowiedzieć się, która wersja MySQL jest zainstalowana.

Główne źródła: pakiet default-mysql-server biblioteki Debian Bookworm i podręcznik wykorzystania pamięci MySQL 8.0 .

Jak można stwierdzić, czy OOM zabił bazę danych?

Najpierw odróżnij zamknięcie jądra z powodu braku pamięci (OOM) od błędu bazy danych, restartu usługi, ponownego uruchomienia lub problemu z dyskiem. W Debianie journalctlodczytuje dziennik systemd. Przeszukaj bieżący rozruch i sprawdź dziennik serwisowy 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

Jeśli w dzienniku jądra znajdują się nazwy mariadbdlub mysqldkomunikat OOM, masz dowód na zabicie pamięci. Jeśli nie ma pasującego wpisu, sprawdź własny dziennik błędów usługi oraz historię restartu lub monitorowania dostawcy. Dzienniki mogą być niedostępne po restarcie, jeśli dziennikowanie nie jest trwałe, a dostawca zarządzanego serwera VPS może ujawnić tylko część diagnostyki hosta.

Przechwyć dane bazowe, gdy serwer znajduje się pod wpływem reprezentatywnego ruchu, a nie tylko gdy jest bezczynny:

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

W kolumnach i vmstatobserwuj ciągłą aktywność wymiany. Niezerowa alokacja pamięci wymiany sama w sobie nie stanowi problemu; ciągła wymiana w połączeniu z długim czasem reakcji wskazuje na obciążenie pamięci. Linux dokumentuje obsługę OOM jako ostateczną odpowiedź, gdy nie można odzyskać wystarczającej ilości pamięci. Zapoznaj się z koncepcją zarządzania pamięcią jądra Linuksa oraz podręcznikiem Journalctl Debiana .siso

Co należy zmierzyć przed strojeniem?

Rejestruj całkowitą pamięć RAM, bieżące i szczytowe wykorzystanie pamięci wymiany, największe procesy rezydentne, połączenia z bazą danych oraz normalne szczytowe obciążenie aplikacji webowej. Baza danych współdzieli pamięć z systemem Debian, serwerem webowym, pracownikami aplikacji, agentami monitorującymi i pamięcią podręczną systemu plików. Serwer VPS może również mieć limit pamięci kontenera lub grupy cgroup niższy niż fizyczna pamięć RAM hosta; rozmiar pamięci podręcznej bazy danych powinien odpowiadać limitowi pamięci widocznemu dla usługi, a nie większej łącznej wartości hosta.

W przypadku MariaDB sprawdź bieżące ustawienia związane z pamięcią i szczytowym poziomem połączenia:

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

Pula buforów InnoDB buforuje strony tabel i indeksów. Limity połączeń i bufory zapytań mogą zwiększać zapotrzebowanie na pamięć wraz ze wzrostem liczby równoczesnych zadań. Należy unikać mnożenia każdego bufora na połączenie przez tak długi czas, max_connectionsjakby każdy bufor był zawsze w pełni przydzielony, ale należy traktować bardzo wysoki limit połączeń jako ryzyko w przypadku gwałtownych wzrostów obciążenia. Przewodnik MariaDB dotyczący pamięci zaleca jednoczesne ustalanie rozmiaru globalnych buforów, buforów na połączenie i ustawień silnika, a w szczególności odnosi się do pul połączeń aplikacji. Przeczytaj przewodnik MariaDB dotyczący alokacji pamięci i jego przewodnik dotyczący obsługi zbyt dużej liczby połączeń .

Jak odpowiednio dostosować rozmiar bazy danych MariaDB na małym serwerze VPS?

Wprowadzaj zmiany pojedynczo, zachowaj kopię oryginalnej konfiguracji i testuj podczas przerwy konserwacyjnej, czy restart wpłynie na użytkowników. Spakowana konfiguracja MariaDB Debiana zazwyczaj zawiera pliki w katalogu /etc/mysql/mariadb.conf.d/; przed edycją sprawdź aktywne katalogi include w instalacji. Mały plik dodany jest łatwiejszy do usunięcia niż zastąpienie głównego pliku dostawcy:

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

W przypadku współdzielonego serwera VPS z około 1 GiB pamięci RAM poniższy przykład stanowi jedynie ostrożny punkt wyjścia, a nie uniwersalny, bezpieczny profil. Obniż lub podwyższ wartości w oparciu o zmierzone maksymalne zużycie pamięci, rozmiar bazy danych, obciążenie oraz ilość pamięci RAM pozostawionej dla systemu operacyjnego i aplikacji:

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

MariaDB odczytuje ustawienia z plików opcji podczas uruchamiania; sprawdź obsługiwane nazwy sekcji i wartości efektywne w swojej wersji. Jeśli ten plik się nie załaduje, usuń moduł i sprawdź dziennik. Ponowne uruchomienie bazy danych przerywa istniejące połączenia, więc zaplanuj je odpowiednio:

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

Oceniaj wynik zarówno pod kątem stabilności, jak i jakości usług. Mniejsza pula buforów może zmniejszyć liczbę trafień w pamięci podręcznej i zwiększyć liczbę odczytów z dysku. max_connectionsZbytnie obniżenie może natomiast powodować błędy „Zbyt wiele połączeń”. Porównaj Max_used_connectionsze skonfigurowanym limitem i sprawdź rozmiary puli aplikacji przed ponowną zmianą limitu. Jeśli baza danych nadal jest zamykana podczas normalnego szczytowego ruchu lub czas odpowiedzi ulega pogorszeniu z powodu długotrwałej wymiany dysków, przejdź na większą warstwę pamięci RAM lub oddziel bazę danych od aplikacji.

Czy swap może zapobiec awarii OOM?

Swap zapewnia Linuksowi wolniejsze miejsce do przenoszenia niektórych stron pamięci i może absorbować chwilowe skoki obciążenia. Nie dodaje szybkiej pamięci RAM, nie naprawia wycieków ani nie sprawia, że ​​zbyt mały VPS nadaje się do długotrwałego obciążenia. Intensywne używanie swapu może spowodować, że zarówno baza danych, jak i aplikacja przestaną odpowiadać. Przed utworzeniem swapu sprawdź, czy Twój dostawca obsługuje pliki swap i czy VPS ma wystarczająco dużo miejsca na dysku.

Jeśli jest to obsługiwane, plik wymiany o rozmiarze 1 GiB można utworzyć w następujący sposób. Dostosuj rozmiar do zaleceń dostawcy i dostępnego dysku, a następnie sprawdź wynik każdego polecenia:

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

Aby włączyć tę funkcję po ponownym uruchomieniu, należy dodać ten wpis po /etc/fstabsprawdzeniu, czy nie istnieje już odpowiedni wpis:

/swapfile none swap sw 0 0

Następnie sprawdź plik za pomocą sudo findmnt --verify --verbosei potwierdź, że pojawia się w swapon --show. Jeśli fallocatenie jest obsługiwany przez system plików lub dostawca blokuje wymianę, zatrzymaj i skorzystaj z procedury obsługiwanej przez dostawcę. Nie wyłączaj programu OOM Killer ani nie przypisuj MySQL ekstremalnego poziomu ochrony przed OOM: nie tworzy to pamięci i może narazić resztę małego VPS na większe ryzyko.

Skąd wiesz, że zmiany przyniosły efekt?

Obserwuj VPS przez co najmniej jeden normalny okres wzmożonej aktywności. Dobry wynik ma kilka oznak:

• Brak nowych wpisów OOM-kill jądra podczas obciążenia pracą, które poprzednio wywołało incydent.
• MariaDB pozostaje aktywna, a liczba ponownych uruchomień nie wzrasta niespodziewanie.
• vmstat 1nie pokazuje ciągłego włączania i wyłączania się podczas normalnego ruchu.
• Aplikacja pozostaje responsywna, a szczytowe wartości połączeń z bazą danych utrzymują się poniżej nowego limitu, bez błędów połączenia.
• Kopie zapasowe są wykonywane, a zapytania do bazy danych nadal spełniają akceptowalne dla aplikacji opóźnienia.

Nie używaj „uruchomienia usługi” jako jedynego testu powodzenia. Ustawienie, które utrzymuje MariaDB przy życiu, ale wymusza ciągłe przenoszenie danych do systemu, nie rozwiązało podstawowego problemu z przepustowością. Podobnie, jeden spokojny dzień nie weryfikuje comiesięcznego importu, kopii zapasowej, skoków ruchu ani zadania wsadowego, które jeszcze się nie uruchomiło.

Kiedy tuning przestaje być właściwym rozwiązaniem?

Wybierz większy serwer VPS lub rozłóż obciążenia, gdy pamięć pozostaje obciążona po rozsądnych dostosowaniach pamięci podręcznej i współbieżności, aktywność wymiany jest utrzymywana, opóźnienia zapytań stają się niedopuszczalne lub aplikacja wielokrotnie osiąga nowy limit połączeń. Rozmiar bazy danych również ma znaczenie: zbyt mała pula buforów może zapobiec skokom obciążenia pamięci, jednocześnie czyniąc wejście/wyjście dysku nowym wąskim gardłem. Jeśli aplikacja i baza danych mają ostre, ale przewidywalne szczyty obciążenia, najpierw sprawdź, czy aplikacja otwiera nadmierną liczbę połączeń lub wykonuje jednocześnie zadania wymagające dużej ilości pamięci.

W systemie Oracle MySQL, a nie w domyślnej MariaDB systemu Debian, przed zastosowaniem tych przykładów należy sprawdzić nazwę usługi, ścieżkę do pliku opcji i zmienne pamięci w wersji podręcznika danego serwera. W obu silnikach należy zachować przetestowane kopie zapasowe i zmieniać zmienne pojedynczo. Wiarygodny wynik nie oznacza gwarancji, że Linux nigdy nie będzie obsługiwał braku pamięci (OOM); jest to dowód na to, że serwer VPS ma wystarczającą rezerwę mocy obliczeniowej na potrzeby rzeczywistego obciążenia szczytowego i że MySQL lub MariaDB nie są już powtarzającymi się ofiarami.

Dodatkowe podstawowe odniesienia: wskazówki dotyczące rozwiązywania problemów podczas uruchamiania MariaDB , w których zaznaczono, że serwer potrzebuje również pamięci dla innych silników, buforów dla każdego połączenia i systemu operacyjnego, a także podręcznik referencyjny MySQL 8.0 .