Przejdź do treści 
CloudLinux MySQL Governor ogranicza obciążenie bazy danych na konto i rozdziela je sprawiedliwie, dzięki czemu pojedyncze zapytania nie spowalniają całego serwera hostingowego. Korzystam z MySQL Governor, aby monitorować w czasie rzeczywistym wykorzystanie procesora oraz operacje odczytu i zapisu dla poszczególnych użytkowników oraz automatycznie ograniczać je w przypadku przekroczenia limitów.
Punkty centralne
- Konto Pro zamiast limitów globalnych
- CPU/ODCZYT/ZAPIS sterować oddzielnie
- Tryby Tryb „tylko monitor” i nadużycia li>LVE jako drugi poziom ochrony
- Narzędzia CLI do kontroli
Dlaczego pojedyncze zapytania spowalniają całość
W środowiskach hostingu współdzielonego zazwyczaj generuje je niewielka liczba Zapytania największe obciążenie, a nie rozmiar baz danych. Często zauważam, że błędne zapytanie lub wtyczka generująca duże obciążenie wejścia/wyjścia nagle monopolizuje czas procesora, a opóźnienia dla innych użytkowników wyraźnie wzrastają. Właśnie w takich sytuacjach z pomocą przychodzi Gubernator ponieważ uwidacznia obciążenie na użytkownika, a nie bierze pod uwagę jedynie średnią ogólną. W ten sposób zapobiegam sytuacji, w której „głośny sąsiad“ spowalnia wszystkie pozostałe projekty, mimo że ich obciążenia są w normie. Dzięki jasno określonym limitom i sprawiedliwemu rozkładowi obciążenia mogę przewidywać czasy odpowiedzi i eliminować podstawy do nadmiernego wykorzystania zasobów.
Tak działa MySQL Governor w codziennej praktyce
Często zaczynam w Monitortryb „-only”, aby zmierzyć rzeczywiste wykorzystanie bez ingerencji. Następnie włączam tryb „Abusen”, który automatycznie przenosi konta wykazujące nadmierną aktywność do środowiska z ograniczeniami, co pozwala natychmiast ograniczyć skutki. Pomiar opiera się na Wątek-Statystyki dla każdego połączenia z MySQL/MariaDB, dzięki czemu można prześledzić wykorzystanie procesora oraz udział operacji odczytu i zapisu dla poszczególnych użytkowników. W przypadku utrzymującego się przeciążenia uruchamia się dodatkowo przypisany mechanizm LVE, co powoduje dalsze spowolnienie procesów tych kont. Ten dwuetapowy proces zapobiega eskalacji, łagodzi szczyty obciążenia i niezawodnie chroni projekty, które nie są z tym związane.
Rozsądny dobór wartości granicznych i przedziałów czasowych
Ustalam limity dla kilku Interwały, tak aby tolerować krótkotrwałe skoki obciążenia, ale niezawodnie zapobiegać długotrwałemu przeciążeniu. Krótkie przedziały czasowe mogą charakteryzować się wyższymi wartościami, średnie – umiarkowanymi, a długie – zdecydowanie bardziej rygorystycznymi, przy czym powinny one pozostawać poniżej ogólnych limitów LVE. Obciążenie procesora mierzę jako procent na Rdzeń; w przypadku ośmiu rdzeni 100% odpowiada jednemu pełnemu rdzeniowi, dzięki czemu podział obciążenia i sprawiedliwość pozostają przejrzyste. Parametry READ i WRITE oceniam na podstawie rzeczywistych operacji wejścia/wyjścia na dyskach, czyli bez trafień w pamięć podręczną, aby zobaczyć rzeczywiste obciążenie pamięci masowej. Aby uzyskać przejrzystą konfigurację ogólną, kieruję się sprawdzonymi zasadami LVE oraz szczegółami opisanymi w Prawidłowa konfiguracja limitów LVE opisane.
Planowanie interwałów według pory dnia i profili
Chętnie to zdeponuję profile zależne od pory dnia: W godzinach szczytu dopuszczam nieco dłuższe krótkie interwały, aby uwzględnić uzasadnione szczyty ruchu (np. błyskawiczne wyprzedaże w sklepie). Wieczorem i w nocy skupiam się przede wszystkim na długie odstępy czasu bardziej restrykcyjne, aby długotrwałe zadania nie wyczerpały pojemności dysku bez naszej wiedzy. Dla okien zadań wsadowych definiuję własne profile z nieco większym WRITE, ale ograniczonym CPU, tak aby importy przebiegały szybko, ale nie zajmowały wszystkich zasobów. Ważne jest to, że nigdy nie zmieniam wszystkich parametrów jednocześnie. Najpierw dostosowuję obciążenie procesora, obserwuję, a dopiero potem parametry READ/WRITE. Każda zmiana ma wyznaczony jasno określony okres obserwacji, aby można było wyraźnie oddzielić przyczynę od skutku.
Narzędzia CLI i szybka diagnostyka
Analizuję podejrzane konta za pomocą dbtop w czasie rzeczywistym zapisuję limity za pomocą dbctl i przeglądam dane historyczne za pomocą lveinfo –dbgov. Narzędzia te w ciągu kilku sekund dostarczają mi istotnych informacji dotyczących wartości szczytowych, długotrwałych zapytań oraz liczby połączeń na użytkownika. W ten sposób mogę stwierdzić, czy przede wszystkim CPU lub ograniczenia wejścia/wyjścia, czy połączenia się rozrastają, czy też poszczególne tabele powodują zatory w zapytaniach. Na podstawie tych wzorców ustalam odpowiednie wartości progowe dla poszczególnych przedziałów czasowych i najpierw testuję zmiany w trybie wyłącznie monitorowania. Dopiero gdy krzywe wykazują uzasadniony spadek, aktywuję ograniczenie na stałe.
| Narzędzie | Cel | Przykład |
|---|---|---|
| dbtop | Liczba wyświetleń na żywo na użytkownika/wątek | dbtop – według użytkownika |
| dbctl | Ustalanie limitów i sterowanie trybami | dbctl set userX cpu=120 read=8 write=6 |
| lveinfo –dbgov | Sprawdź historię i naruszenia | lveinfo –dbgov –id userX –period 1h |
Wykrywanie błędów: typowe schematy i szybkie działania zaradcze
Kiedy CPU gdy analizuję dane z konta, często natrafiam na wzorce takie jak SELECT *, brakujące klauzule WHERE, złożone ORDER BY z dużymi zestawami wyników lub zapytania N+1 z ORM. Jeśli chodzi o operacje wejścia/wyjścia (I/O), dostrzegam pełne skanowanie bez odpowiednich indeksów, powtarzające się wyrażenia typu LIKE ‚%…%‘ lub połączenia (JOIN) na kolumnach bez indeksów. Moja procedura: identyfikacja tabel, których to dotyczy, sprawdzenie planu zapytania, dodanie brakujących indeksów i optymalizacja zapytania usprawnić (tylko niezbędne kolumny, paginacja za pomocą LIMIT/OFFSET lub metod opartych na kursorze). Równolegle ustalam dla tego użytkownika tymczasowo bardziej rygorystyczne krótkie odstępy czasu, aby natychmiast złagodzić szczyt, a następnie poluzuj je ponownie, gdy tylko poprawka zacznie działać, a krzywa zacznie stabilnie opadać.
Współdziałanie z LVE: dwustopniowa kontrola
Uważam MySQL Governor za pierwszy Warstwa ochrony bazy danych oraz LVE jako dodatkowy mechanizm hamujący w przypadku długotrwałego obciążenia. Regulator celowo ogranicza aktywność bazy danych, podczas gdy LVE dodatkowo ściśle kontroluje łączne wykorzystanie procesora, pamięci RAM i operacji wejścia/wyjścia na koncie. Takie połączenie zapobiega wymknięciu się konta spod kontroli poprzez samo powtarzanie krótkich zapytań. Jeśli aktywność pozostaje wysoka, uruchamia się LVE i obniża priorytet procesu danego konta, co w zauważalny sposób odciąża bazę danych. Dzięki temu jakość usług dla wszystkich klientów pozostaje na niezawodnym poziomie, nawet podczas okresów wzmożonego obciążenia i szczytów ruchu.
Wartości graniczne w praktyce: przykładowe wartości
W przypadku typowych serwerów współdzielonych zaczynam od CPU-Limity w przedziale 80–150% na konto w krótkim przedziale czasowym, a w długim przedziale znacznie je zmniejszam. Prędkość odczytu/zapisu często ustalam początkowo na poziomie 4–12 MB/s w perspektywie krótkoterminowej, a w dłuższej perspektywie zawężam te wartości, aby dysk nie popadł w stan ciągłego oczekiwania. Liczbę jednoczesnych połączeń chętnie ograniczam do 30, ponieważ nadmierna liczba połączeń szybko wyczerpuje pule wątków. Takie wartości początkowe stanowią dobrą podstawę, ale dostosowuję je na podstawie rzeczywistych danych z dbtop i lveinfo. Najważniejsze jest to, że dopuszczam krótkotrwałe szczyty obciążenia, ale konsekwentnie zapobiegam długotrwałemu wyczerpywaniu zasobów.
Wyjątki, listy dozwolone i okna serwisowe
Niektóre konta potrzebują czasami więcej przestrzeni: duże Import, migracje sklepów, ponowne indeksowanie. Planuję takie działania w przedziałach czasowych poza godzinami szczytu i z wyprzedzeniem ustalam tymczasowo wyższe limity dla poszczególnych użytkowników. Po zakończeniu przywracam wartości domyślne za pomocą skryptu. Równie sensowne jest niewielkie Whitelist dla kont o znaczeniu systemowym, które nigdy nie powinny być ograniczane (np. wewnętrzni użytkownicy serwisowi). Dokumentuję każdy wyjątek, podając godzinę rozpoczęcia i zakończenia oraz wartości docelowe, aby późniejsze analizy mogły wyjaśnić to odchylenie. Dzięki temu zarządzanie pozostaje przejrzyste, nie utrudniając jednocześnie uzasadnionych prac konserwacyjnych.
WordPress i wtyczki: jak zapobiegać typowym problemom
W konfiguracjach CMS często widzę drogie WSPÓLNE, dynamiczne widżety bez pamięci podręcznej oraz zadania cron, które co godzinę przeszukują pełne tabele. Governor zapewnia tu niezawodną ochronę, ale dodatkowo eliminuję przyczynę problemu na poziomie aplikacji. Włączam pamięć podręczną obiektów, ograniczam zapytania wyszukiwania i tam, gdzie to ma sens, korzystam z Łączenie połączeń, aby uniknąć burz połączeń i rozłączeń. W połączeniu z jasno określonymi limitami obciążenia procesora i wejść/wyjść zauważalnie skracam czasy odpowiedzi i utrzymuję Obciążenie można kontrolować. Takie połączenie pozwala ograniczyć liczbę zgłoszeń do pomocy technicznej i łagodzi szczyty obciążenia, zanim zaczną one obciążać serwer.
Utrzymanie porządku w schematach i indeksach w praktyce
Regularnie sprawdzam, czy tabele i indeksy nadal są przydatne dla Wzorzec dostępu dopasować. Nowe funkcje i wtyczki często w subtelny sposób zmieniają zapytania: dodatkowy filtr, inne kryterium sortowania – i już stary indeks przestaje działać. Dlatego nadaję priorytet indeksom dla często używanych kolumn WHERE, ograniczam nakładające się indeksy i zastępuję wyszukiwanie z prefiksem LIKE bardziej precyzyjnymi polami. W przypadku tabel archiwalnych stosuję koncepcje partycjonowania lub filtry oparte na sygnaturach czasowych, aby uniknąć pełnego skanowania. Governor łagodzi skutki nieodpowiednich schematów, ale najskuteczniejsze jest przetwarzanie danych łatwy w obsłudze uporządkować.
Zarządzanie połączeniami: jak uniknąć błędu 500
Zbyt duża liczba jednoczesnych połączeń często powoduje przerwy w działaniu usług Limity czasu, które objawiają się jako błędy 500. Najpierw sprawdzam liczbę połączeń na użytkownika oraz obciążenie puli wątków. Jeśli pojawiają się oznaki nadmiernej liczby połączeń, zaostrzam limity i wprowadzam buforowanie na poziomie zapytań lub obiektów. Dodatkowe wyjaśnienia można znaleźć w artykule na temat Błąd 500 spowodowany połączeniami typowe przyczyny i sposoby zaradzenia temu wąskiemu gardłu. Podsumowując, dbam o bezpieczeństwo stosu MySQL i utrzymuję Opóźnienie przewidywalny.
Właściwe wyważenie funkcji poolingu i keep-alive
Zajmuję się projektowaniem basenów mały, ale stały: wystarczająco dużo, by obsłużyć typową równoległość, nie blokując serwera sesjami bezczynnymi. Długie czasy utrzymywania połączenia (Keep-Alive) wyrównują szczyty obciążenia, ale nie mogą prowadzić do sytuacji, w której wiele uśpionych połączeń zajmuje zasoby. Dlatego mierzę czas trwania sesji i czas bezczynności dla każdego konta oraz odpowiednio dostosowuję wielkość pul i limity czasu sesji. W połączeniu z mechanizmem Governor zapobiegam w ten sposób, aby chaotyczne nawiązywanie i zrywanie połączeń nie obciążało procesora, a jednocześnie zbyt duże pule nie zajmowały niepotrzebnie puli wątków.
Jak prawidłowo interpretować wskaźniki monitorowania
Dokonuję wyraźnego rozróżnienia między CPU oraz operacje wejścia/wyjścia (I/O), ponieważ oba te zasoby nakładają zupełnie inne ograniczenia. Jeśli obciążenie procesora (CPU) gwałtownie wzrasta bez odpowiednich wartości I/O, często przyczyną jest blokada logiki, parsowanie lub nieefektywny plan; przy wysokim obciążeniu I/O i niskim obciążeniu procesora (CPU) przyczyną wąskiego gardła są zazwyczaj pełne skanowania lub brak indeksów. Parametry READ/WRITE zawsze oceniam bez uwzględnienia pamięci podręcznej, aby rozpoznać rzeczywiste obciążenie dysków, a nie tylko dostępy do pamięci. Ponadto analizuję czas trwania połączeń, liczbę aktywnych wątków oraz długość zapytań, aby wcześnie wykryć powolne operacje. Na podstawie tych wzorców ustalam, jakie progi zastosować i w jakim zakresie zaostrzyć interwały.
Uwzględnienie czynników związanych ze sprzętem i silnikiem
Die Klasa pamięci masowej określa, jakie wartości graniczne są realne. W przypadku NVMe mogę na krótką metę dopuścić wyższe wartości odczytu i zapisu, natomiast w przypadku dysków HDD planuję bardziej konserwatywnie i ściślej przestrzegam długich interwałów. Zwracam również uwagę na sposób buforowania przez silnik: agresywne operacje zapisu w tle mogą wygładzać szczyty, ale mogą też powodować pozornie „spokojne“ fazy, w których operacje zapisu są realizowane z opóźnieniem. Dlatego koreluję wskaźniki regulatora z fizycznymi operacjami wejścia/wyjścia oraz czasami oczekiwania na urządzeniu blokowym. Celem jest zawsze bardziej stabilny Mediana zamiast maksymalnych wartości przepustowości kosztem opóźnienia.
Porównanie trybów „Monitor-only” i „Abusen”
Korzystam z MonitorTryb „-only” służy do gromadzenia rzeczywistych profili użytkowania i ustalania wartości bazowych. Gdy tylko ustalę wiarygodne wartości progowe, przełączam się na tryb „Abusen”, aby regulator automatycznie ograniczał konta w przypadku przeciążenia. Pierwszy tryb ogranicza fałszywe alarmy, drugi zapobiega skutkom ubocznym podczas rzeczywistych szczytów obciążenia. W zależności od poziomu doświadczenia mogę pracować z bardziej rygorystycznymi długimi interwałami, a w krótkich interwałach pozostawić nieco więcej swobody. Taka sekwencja gwarantuje, że limity nie są ustalane na podstawie przeczucia, lecz na podstawie Pomiar nastąpić.
Plan wdrożenia i komunikacja
Nigdy nie uruchamiam urządzenia Governor w trybie „Big Bang“. Procedura jest sprawdzona: 1) Inwentaryzacja aktywnych kont, zgrubne pogrupowanie według profili obciążenia. 2) Tylko monitor przez co najmniej jeden do dwóch tygodni, aby uchwycić wzorce tygodniowe. 3) Określenie limitów bazowych dla każdego klastra oraz kontrolowane wdrażanie w etapach, przy ścisłej obserwacji wskaźników KPI (wskaźnik błędów, opóźnienie P95, wskaźnik przerwanych operacji). 4) Precyzyjne dostosowanie i dokumentacja wyjątków. Równolegle proaktywnie informuję klientów o celu „Fair Share“, typowych przyczynach ograniczeń przepustowości oraz sensownych optymalizacjach. Przejrzystość zmniejsza liczbę zapytań i zwiększa akceptację limitów.
Tworzenie kopii replikacyjnych, kopii zapasowych i zabezpieczanie użytkowników specjalnych
Użytkownicy ściśle związani z systemem, tacy jak Replikacja- lub Użytkownik kopii zapasowej nie mogą być nieoczekiwanie ograniczane. Wyraźnie klasyfikuję takie konta, dokumentuję je i wyłączam z automatycznego ograniczania przepustowości. W przypadku kopii zapasowych planuję limity odczytu poniżej strefy komfortu pamięci masowej, aby nie wpływało to negatywnie na obciążenie użytkowników w tym samym czasie. W przypadku replikacji dbam o to, aby procesy nadrabiania zaległości nie zagrażały obciążeniu produkcyjnemu: krótkie interwały ustalam nieco bardziej liberalnie, a długie – konserwatywnie, tak aby długotrwałe nadrabianie zaległości nie stało się stałym hamulcem. Ważne pozostaje wyraźne rozdzielenie między Serwis- oraz konta klientów, aby wskaźniki pozostały jednoznaczne.
Procedury awaryjne w przypadku nagłego przeciążenia
Jeśli pomimo ustalonych limitów wystąpi zauważalne pogorszenie jakości, wprowadzam Podręcznik taktyczny Od: 1) Zidentyfikować w dbtop konto generujące największe obciążenie i tymczasowo zaostrzyć jego limity. 2) Zmniejszyć limit połączeń dla tego użytkownika, aby odciążyć pulę wątków. 3) Wyświetlić długotrwałe zapytania, a te budzące podejrzenia zoptymalizować w pierwszej kolejności lub wstrzymać. 4) W przypadku dużego obciążenia systemu tymczasowo obniżyć limity LVE sprawcy, aby ustabilizować platformę. 5) Po ustabilizowaniu sytuacji stopniowo przywrócić poprzednie ustawienia i trwale usunąć przyczynę (indeks, pamięć podręczna, kod). Każde działanie rejestruję wraz z datą i godziną oraz zmierzonym efektem, aby przyszłe interwencje przebiegały szybciej.
W skrócie: praktyczne wytyczne
Stawiam na wyraźnie oddzielone Ograniczenia dla CPU, READ i WRITE, ponieważ każdy zasób działa inaczej. Zaczynam ostrożnie, mierzę efekty w trybie „tylko monitorowania” i ustalam limity w trybie „abusen”, gdy tylko krzywe w sposób wiarygodny wskazują, w jakim kierunku zmierzamy. W przypadku długoterminowych interwałów stosuję bardziej rygorystyczne ograniczenia i pozostaję poniżej globalnych limitów LVE, aby w razie potrzeby drugi poziom ochrony zadziałał niezawodnie. Monitoruję liczbę połączeń, zaczynam od 30 sesji na konto i dostosowuję tę liczbę w zależności od obciążenia i pory dnia. Łączę kontrolę techniczną z pracą nad przyczynami w aplikacji, ponieważ w ten sposób utrzymuję Baza danych niezawodne, uczciwe i sprawne rozwiązanie dla wszystkich projektów na tym samym serwerze.
