MySQL Governor: Ograniczanie zasobów bazy danych poszczególnych klientów hostingu

Co ogranicza MySQL Governor

MySQL Governor jest to komponent CloudLinux przeznaczony dla serwerów hostingu współdzielonego, a nie ogólna funkcja MySQL. Monitoruje on obciążenie bazy danych na podstawie przypisanych użytkowników i może ograniczać zapytania w przypadku przekroczenia progów za pomocą lekkich środowisk wirtualnych (Lightweight Virtual Environments, w skrócie LVE). W ten sposób obciążenie poszczególnych kont hostingowych można analizować w sposób bardziej zróżnicowany niż tylko na podstawie całkowitego obciążenia serwera bazy danych.

W centrum uwagi znajdują się Procesor i operacje wejścia/wyjścia dysków twardych: Moduł Governor monitoruje obciążenie obliczeniowe oraz aktywność związaną z odczytem i zapisem. Wysokie obciążenie może wynikać na przykład z importu danych lub często wykonywanego zapytania w sklepie. Przypisanie do konta pozwala uwidocznić to obciążenie; to, czy jest ono odpowiednie dla danej operacji, należy następnie ocenić w kontekście.

Limit bazy danych dla tych zasobów nie jest limitem miejsca na dysku. Duża, rzadko używana baza danych może powodować niewielkie bieżące obciążenie procesora i operacji wejścia/wyjścia; z drugiej strony mała baza danych może być silnie obciążona przez wiele wymagających operacji dostępu. Również limity połączeń odpowiadają na inne pytanie: ograniczają one liczbę operacji dostępu, ale nie zastępują automatycznie kontroli obciążenia procesora i operacji wejścia/wyjścia.

Jeśli zapytanie zostanie ograniczone, nie oznacza to koniecznie, że jest ono błędne. Ograniczenie to może chronić inne konta przed dużym obciążeniem, ale jednocześnie spowolnić działanie prawidłowej aplikacji. Nie wynika z tego gwarancja czasów odpowiedzi, ponieważ usługa bazy danych, sprzęt i inne komponenty aplikacji pozostają wspólnie wykorzystywanymi elementami systemu.

Aby zrozumieć wzajemne powiązania między kontami, obciążeniami i pozycjami LVE, pomocny jest uzupełniający przegląd dotyczący Ograniczanie obciążenia bazy danych za pomocą narzędzia CloudLinux MySQL Governor kolejny punkt wyjścia. Decydujące znaczenie dla konkretnej konfiguracji mają rzeczywiste środowisko instalacyjne oraz obowiązujące w nim ustawienia.

Sprawdź wersję i zgodność

Przed zaplanowaniem limitów bazy danych należy najpierw sprawdzić Wydanie i licencja. Według producenta system CloudLinux OS Admin nie zawiera komponentu MySQL Governor. Sam fakt posiadania systemu CloudLinux nie stanowi zatem dowodu na to, że komponent ten jest dostępny dla wybranej edycji, objęty licencją i zainstalowany na serwerze.

Następnie należy wziąć pod uwagę kombinację wersji CloudLinux, pakietu Governor oraz serwera bazy danych. MySQL i MariaDB to odrębne gałęzie rozwoju: fakt, że dana wersja MySQL jest obsługiwana, nie oznacza, że wersja MariaDB o tym samym numerze będzie działać w tych samych warunkach. Należy również sprawdzić używany panel sterowania oraz jego integrację.

Minimalne wymagania pokazują, dlaczego ogólne zatwierdzenie nie wystarczy: w przypadku MySQL 8.4 firma CloudLinux wymaga co najmniej wersji MySQL Governor 1.2-129. MariaDB 11.4 wymaga co najmniej wersji 1.2-122 programu Governor i nie jest obsługiwana w systemie CloudLinux OS 7 zgodnie z dokumentacją producenta. Informacje te dotyczą wymienionych gałęzi i nie zastępują sprawdzenia pozostałych kombinacji.

Producent wymienia jako środowiska instalacyjne między innymi cPanel, Plesk, DirectAdmin, ISPmanager i InterWorx, a także serwery bez panelu sterowania. W przypadku innego panelu lub panelu zintegrowanego samodzielnie należy osobno wyjaśnić kwestię konkretnego wsparcia, a zwłaszcza przypisania użytkowników. Wymieniona wersja bazy danych nie stanowi gwarancji zgodności z każdą kombinacją panelu i systemu operacyjnego.

Przed wprowadzeniem zmian zapisz aktualne wersje i pakiety, a następnie porównaj je z dokumentacją dotyczącą planowanej konfiguracji docelowej. W ten sposób zorientujesz się, czy konieczna byłaby najpierw wymiana komponentów, zamiast uznawać istniejącą instalację za zgodną wyłącznie na podstawie nazwy bazy danych.

Przypisywanie kont hostingowych do użytkowników bazy danych

Aby obciążenie mogło zostać przypisane do konkretnego klienta hostingu, musi istnieć zgodność między użytkownikami bazy danych a kontami hostingowymi. W przypadku integracji z panelem administracyjnym zazwyczaj wykorzystuje się w tym celu plik /etc/container/dbuser-map aktualizowane. Gubernator wprowadza zmiany w tym przyporządkowaniu zgodnie z dokumentacją integracyjną w ciągu pięciu minut.

Przykład: Konto hostingowe obsługuje sklep internetowy i oddzielny blog, z których każdy korzysta z własnego użytkownika bazy danych. Jeśli obaj użytkownicy są przypisani do tego samego konta, obciążenie bazy danych można rejestrować zgodnie z tym kontem. Jeśli brakuje jednego z wpisów lub wskazuje on na niewłaściwe konto, wyświetlane przyporządkowanie nie jest wiarygodne dla oceny związanej z klientem.

Sprawdź Przypisanie użytkowników Dlatego nie chodzi tylko o pierwszą instalację. Również po utworzeniu lub przeniesieniu baz danych i użytkowników panel musi prawidłowo aktualizować przypisania. Podczas sprawdzania bezpośrednio po wprowadzeniu zmiany należy uwzględnić udokumentowany czas na aktualizację, zanim na podstawie nadal aktualnego stanu wyciągniesz wniosek o trwałym błędzie.

Szczególnie istotny jest brak mapowania w trybie „Abusers”: według producenta tryb ten emuluje wówczas tryb „Single”. Klienci z ograniczeniami dzielą w trybie „Single” wspólną, ograniczoną przestrzeń LVE, zamiast być ograniczeni w swoich własnych przestrzeniach LVE. Sam fakt włączenia trybu „Abusers” nie świadczy zatem jeszcze o tym, że zamierzone ograniczenie indywidualne dla każdego konta faktycznie obowiązuje.

W przypadku nieprawidłowości należy porównać z sobą użytkowników bazy danych, których to dotyczy, aktualne przypisania oraz wybrany tryb pracy. Nawet prawidłowe mapowanie nie gwarantuje całkowitej izolacji: usługa bazy danych i sprzęt, na którym działa, są nadal współużytkowane. Przyporządkowanie jest warunkiem koniecznym do sterowania dostosowanego do potrzeb klienta, a nie substytutem planowania wydajności.

Porównanie trybów pracy

Tryb pracy określa, czy MySQL Governor jedynie monitoruje obciążenie bazy danych, czy też wykonuje zapytania w ograniczonym środowisku. Przy dokonywaniu wyboru nie liczą się wyłącznie wartości progowe: na działanie mają wpływ również przypisanie użytkowników bazy danych oraz to, którzy klienci współdzielą jeden LVE.

Aby sporządzić spis, warto skorzystać z Wył. Uwaga: Obserwowane wykorzystanie wskazuje, które konta i przedziały czasowe zasługują na dokładniejszą analizę, bez konieczności ograniczania zapytań przez Governor. Pojedyncza wysoka wartość chwilowa nie pozwala jednak stwierdzić, czy dane konto generuje stałe duże obciążenie, czy też właśnie wykonuje uzasadnione prace konserwacyjne.

Na stronie Osoby nadużywające Ograniczone zapytania do bazy danych dzielą budżet zasobów LVE z innymi procesami tego samego konta, na przykład z procesami PHP. Ograniczenie to może zatem nie tylko wydłużyć czas wykonywania zapytań: aplikacja może również reagować wolniej, jeśli jej procesy konkurują o te same ograniczone zasoby. Z drugiej strony, już wykorzystany budżet PHP może wpływać na działanie bazy danych.

Tryb „Single” jest przestarzały i ma znaczenie przede wszystkim w przypadku istniejących konfiguracji oraz udokumentowanego zachowania zastępczego: kilku klientów z ograniczeniami współdzieli jedno środowisko i może tam ze sobą konkurować. W przypadku braku pliku dbuser-map program Abusers emuluje to zachowanie; na podstawie samego wybranego ustawienia nie można wówczas wywnioskować, że chodzi o ograniczenie właściwe dla danego klienta. Również opcja „All” jest przestarzała i nie jest standardowo zalecana przy nowej instalacji.

Planowanie limitów bazy danych i przedziałów czasowych

MySQL Governor rozróżnia wykorzystanie procesora oraz operacje wejścia/wyjścia związane z odczytem i zapisem. Udokumentowany interfejs CLI wyświetla wykorzystanie procesora w procentach, a operacje wejścia/wyjścia w MB/s; dla odczytu i zapisu można skonfigurować oddzielne wartości. Wielkości te opisują różne rodzaje obciążenia: operacja wymagająca dużej mocy obliczeniowej niekoniecznie wiąże się z intensywnym zapisem na nośniku danych.

Progi bieżący, krótki, średni i długi Uwzględniają one wykorzystanie krótkotrwałe i długotrwałe. Ich przekroczenie powoduje wprowadzenie ograniczenia w zależności od trybu pracy i konfiguracji. Nie stanowią one ani gwarantowanej przepustowości, ani czterech niezależnych od siebie, stale i rygorystycznie egzekwowanych gwarancji wydajności. To, które ograniczenie faktycznie zadziała, zależy również od wybranej metody oraz limitów LVE.

Import dobrze ilustruje tę różnicę: jeśli obciążenie zapisem krótkotrwale wzrasta, a następnie ponownie spada, może to być częścią zaplanowanego procesu. Jeśli natomiast utrzymuje się na wysokim poziomie przez dłuższy czas, import dłużej angażuje zasoby. Aby podjąć decyzję, oprócz wartości szczytowej należy sprawdzić, który zasób jest zaangażowany, jak długo trwa operacja i czy się powtarza.

Niski Progi uruchomienia mogą wcześniej chronić innych klientów przed długotrwałym obciążeniem, ale mogą też spowalniać uzasadnione operacje importu lub konserwacji. Wysokie progi dają większą swobodę działania przy takich zadaniach, ale jednocześnie pozwalają na dłuższe utrzymywanie wyższego obciążenia. Okno konserwacyjne lub celowo zaplanowana przepustowość mogą być bardziej sensownym rozwiązaniem niż stały wyjątek.

Należy zaplanować wartości regulatorów w odniesieniu do limitów LVE oraz faktycznie oferowanych taryf. Zalecenia producenta wyraźnie uwzględniają tę zależność; nie można jednak na tej podstawie wywnioskować ogólnie obowiązujących wartości produkcyjnych. Obserwowane obciążenie zapytaniami, wydajność zapytań oraz rodzaj zadań realizowanych przez klientów stanowią podstawę do kontrolowanego dostosowywania progów po wdrożeniu systemu.

Przygotowanie wprowadzenia i limitów taryfowych

Przed instalacją lub aktualizacją należy pełna kopia zapasowa bazy danych w tym tabele systemowe. Należy również zaplanować, w jaki sposób w razie potrzeby ma przebiegać przywracanie danych. Producent zwraca uwagę, że pakiety baz danych można w tym celu aktualizować z repozytoriów CloudLinux; zmiana pakietu nie jest zatem nieistotnym skutkiem ubocznym, który należy sprawdzić dopiero po instalacji.

Następnie sprawdź kombinację edycji i wersji CloudLinux, licencji, gałęzi bazy danych, pakietu Governor oraz panelu sterowania. Sama obsługiwana wersja bazy danych nie oznacza, że każda kombinacja tych elementów jest obsługiwana. Jeśli wersje pakietów lub integracja z panelem sterowania nie są zgodne, przed podjęciem jakichkolwiek działań należy upewnić się co do konkretnej obsługi.

Po zakończeniu przygotowań technicznych zacznij od obserwacji, zamiast od razu ograniczać obciążenie. Porównaj typowe godziny pracy z znanymi oknami importu i konserwacji, sprawdzając przy tym, czy użytkownicy bazy danych są przypisani do właściwych kont hostingowych. Bez wiarygodnego przypisania nie można na podstawie pozornie niskiego obciążenia konta z całą pewnością wywnioskować rzeczywistego zapotrzebowania na zasoby.

Na podstawie tej analizy sytuacji opracuj ograniczone wdrożenie: określ, które konta lub taryfy mają zostać objęte zmianami, w jaki sposób będą rejestrowane skargi oraz na podstawie jakich obserwacji będziesz weryfikować ustawienia. Po aktywacji porównuj ograniczenia z operacjami aplikacji, zamiast traktować każde przekroczenie jako niewłaściwe zachowanie.

CloudLinux Manager umożliwia zarządzanie limitami regulatora w odniesieniu do poszczególnych pakietów; dla poszczególnych klientów mogą obowiązywać inne wartości. Dlatego przy każdej zmianie należy udokumentować Źródło limitu: Czy pochodzi to z pakietu, czy zostało ustawione indywidualnie? Dzięki temu będzie można później ustalić, których klientów dotyczy zmiana taryfy, a które wyjątki należy sprawdzić osobno.

Sprawdź aktualne obciążenie i historię

Do postawienia diagnozy potrzebujesz zarówno Migawka jak i przebieg w czasie. Poniższe polecenia są wykonywane w terminalu serwera CloudLinux, a nie w konsoli MySQL. Służą one wyłącznie do wglądu i nie zmieniają żadnych limitów; aby uzyskać miarodajną analizę, należy zainstalować odpowiednie narzędzia i zapewnić dostępność odpowiednich danych.

Znajdź podobne konta, które przyciągają uwagę, za pomocą Przypisanie użytkowników oraz od wybranego trybu pracy. Jeśli w mapowaniu brakuje użytkownika bazy danych, widoczne obciążenie konta hostingowego może być niekompletne. Dokumentacja integracji podaje, że zmiany w pliku mapowania są uwzględniane w ciągu pięciu minut; wynik sprawdzony bezpośrednio po tej operacji może zatem jeszcze nie odzwierciedlać aktualnego stanu.

Następnie porównaj moment wystąpienia ograniczenia z zaobserwowanym przebiegiem korzystania z aplikacji. Wysoka pojedyncza wartość może wynikać z importu i sama w sobie nie stanowi dowodu na trwałe nadmierne korzystanie. Instrukcja dotycząca interpretacji raportów MySQL Governor uzupełnia klasyfikację wyświetlanych wskaźników.

Rozróżnienie między ograniczeniem przepustowości a jego przyczynami

Jeśli strona internetowa działa wolno, najpierw sprawdź, czy w danym momencie obowiązywało jakiekolwiek ograniczenie i jaki powód został podany. Przypisz ten wynik do konkretnego zdarzenia: powolna realizacja zamówienia i import przebiegający w tym samym czasie mogą być ze sobą powiązane, ale nie muszą. Bez zbieżności czasowej zbyt pochopne byłoby uznanie regulatora za jedyną przyczynę.

W trybie „Abusers” wykonywane są ograniczone zapytania do bazy danych w systemie LVE przypisanego konta. Tam dzielą one Budżet zasobów z innymi procesami działającymi na koncie, na przykład PHP. Dlatego w przypadku zgłoszenia problemu należy wziąć pod uwagę obie strony: zadanie intensywnie wykorzystujące bazę danych może konkurować z PHP o zasoby; z drugiej strony już zajęta pojemność LVE może wpływać na spowolnienie zapytań.

Jeśli obciążenie związane z daną funkcją sklepu powtarza się, przeanalizuj dane zapytanie oraz jego Harmonogram zapytań wraz z odpowiednimi statystykami bazy danych. Brak lub nieodpowiedni indeks to jedna z możliwych przyczyn, ale nie jedyna. Ograniczenie może zmniejszyć wpływ na wspólnie wykorzystywane zasoby; nie koryguje ono jednak ani planu, ani logiki aplikacji.

W przypadku planów Single i Abusers CloudLinux informuje, że ograniczenia zostają zniesione po upływie minuty, w której zużycie spadło poniżej progu. Należy jednak sprawdzić faktycznie skonfigurowany mechanizm ograniczania oraz przebieg czasowy w własnym systemie, zamiast wyciągać wnioski o trwałym rozwiązaniu na podstawie krótkotrwałego spadku obciążenia. Zadanie uruchomione ponownie może później ponownie przekroczyć próg.

Dostosować limity lub zmienić architekturę

Rozpocznij analizę od ustalenia, czy zaobserwowany szczyt obciążenia wynika z planowanego zadania, czy też regularnie zakłóca działanie systemu. Zaplanowany import można ewentualnie przełożyć na okno serwisowe. Przed wyciągnięciem wniosków o trwałej zmianie taryfy na podstawie pojedynczego odchylenia należy odnotować czas trwania, zasoby, których to dotyczy, oraz wpływ na aplikację.

Jeśli ten przedział czasowy okaże się niewystarczający, można zastosować ukierunkowane Wyjątek taryfowy może być bardziej odpowiednie niż ogólne podwyższenie limitu dla wszystkich klientów. Udokumentuj powód, osobę odpowiedzialną oraz datę ponownej weryfikacji. Odnotuj również, czy dotychczasowa wartość pochodzi z pakietu, czy została ustawiona indywidualnie: CloudLinux Manager obsługuje limity związane z pakietami oraz indywidualne odstępstwa.

Po wprowadzeniu zmiany sprawdź w reprezentatywnym okresie, czy planowana praca przebiega sprawniej oraz czy w innych obszarach pojawiają się ograniczenia lub problemy. W tym celu porównaj progi regulatorów z limitami LVE. Wyższy próg potencjalnie pozwala na dłuższe utrzymywanie większego obciążenia; nie stanowi on jednak gwarancji przepustowości ani zapewnienia określonych czasów odpowiedzi.

Kolejnym elementem regulacyjnym jest usunięcie przyczyny: Optymalizacja zapytań, odpowiednie indeksy lub buforowanie mogą ograniczyć powtarzające się zadania, a nie tylko łagodzić ich skutki. Z kolei limity połączeń po stronie bazy danych ograniczają liczbę jednoczesnych dostępów i nie zastępują automatycznie kontroli procesora i operacji wejścia/wyjścia realizowanej przez moduł Governor.

Jeśli wymagania klienta trwale znacznie odbiegają od standardów hostingu współdzielonego, sensownym rozwiązaniem może być posiadanie własnej instancji bazy danych lub własnego serwera. Przenosi to jednak decyzję z poziomu poszczególnych progów na planowanie wydajności, konserwacji i eksploatacji. Również takiego rozdzielenia nie należy przedstawiać w sposób ogólny jako gwarancji całkowitej izolacji lub stałych czasów odpowiedzi.