Jak prosty monitoring może zabić MySQL

O tym, że monitorować należy wszystko co można monitorować wie każdy admin z kilkoma latami doświadczenia. To tak jak z backup’ami – zaczynasz je robić regularnie po pierwszej utracie danych.

Narzędzi do monitorowania jest mnóstwo, począwszy od własnych skryptów poprzez rozwiązania typu NAGIOS . Dzisiejsza historia jednak nie będzie o skryptach do monitorowania, tylko o tym jak zły monitoring może spowolnić, albo zabić cały system.

Ostatnimi czasy pracuję nad dosyć dużym rozwiązaniem, które opiera się na dosyć skomplikowanej strukturze. Serwis działa w oparciu o sprzętowy

load balancing który za sobą ma kilkanaście serwerów (więcej niż 12 ;P). Każdy serwer ma swój serwer WWW i jego zadaniem jest hostować skrypty. Wszystko jest podłączone do jednego serwera MySQL.

Ilość sprzętu ma służyć nie zapewnieniu redundancji, ale na zapewnieniu szybkości ponieważ skrypt jest kobylasty i wolny. Load Balancer rozrzuca nam zapytania na poszczególne serwery, dzięki czemu nie martwimy się o przeciążenie jednej maszyny. Wszystkie dane trzymane są na jednym serwerze MySQL który całkiem dobrze radzi sobie z obsługą dużej ilości zapytań.

Jakiś czas temu pojawił się problem, który polegał na tym że od czasu do czasu jeden z serwerów się dławił z niewiadomych przyczyn. Load Balancer ma wspaniała funkcję, które pozwala na monitorowanie poszczególnych maszyn i jeżeli jedna z nich nie odpowiada, to nie jest wykorzystywana do generowania serwowania treści na froncie.

Funkcja do monitorowania nie robi nic innego jak próbuje otworzyć główną stronę na porcie 80. Czyli otwiera stronę jak zwykły użytkownik. Pech chciał, że główna strona jest dosyć “ciężka” jeżeli chodzi o liczbę generowanych zapytań, nie może być cache’owana.

Problem pojawił się, jak monitoring zaczął generować zapytania co 5s na każdy z n-serwerów (n> 12). Co za tym idzie zaczeliśmy generować ogromną ilość zupełnie niepotrzebnych zapytań. Dodatkowo sesje trzymamy w bazie danych MySQL. Przy każdym trafieniu na stronę był generowany wiersz z danymi sesji, które wprawdzie miały ustawiony czas wygaśniecia, ale przy takiej liczbie zapytań pojawiło się sporo niepotrzebnych rekordów.

Oczywiście zdiagnozować problem nie było tak łatwo – pierwsze objawy były nader finezyjne – generujemy ogromną ilość zapytań do bazy danych… bez faktycznego ruchu z zewnątrz. Dopiero po szczegółowym śledztwie udało się znaleźć winowajcę takiego stanu rzeczy 🙂

Rozwiązanie problemu okazało się nader proste – zamiast sprawdzać stronę główną wystarczy otworzyć plik statyczny, który nie generuje żadnych zapytań do MySQL’a.