MySQL powoduje "freeze" serwera

[webmaniac 0]

W ostatnich dniach mam do czynienia z poważnym problemem MySQL. Opiszę go dokładnie.

 

Na serwerze wykorzystywany jest Debian 5 w wersji 64bit wspomagany aplikacją Direct Admin.

 

Konfiguracja DirectAdmin nie odbiega w większym stopniu od domyślnych ustawień. (Apache 2, PHP5, MySQL 5). Wszystkich instalacji dokonywano za pomocą custombuild dostępnego w DirectAdmin.

 

W międzyczasie (zaraz po przeniesieniu na nowy serwer dedykowany) postanowiłem skorzystać dodatkowo z udogodnienia w formie cpulimit, który ograniczał wykorzystanie procesora przez MySQL do 30 procent, zaś wykorzystanie przez httpd do 50 procent. Wszystko spisywało się prawie dobrze, prócz momentów gdy po uruchomieniu więcej trwających cronów (zazwyczaj nad ranem - pobieranie baz produktów do aktualizacji, aktualizacja zapleczy) serwer MySQL się wysypywał. (Przy czym jego wykorzystanie na chwilę przed freezem wskazywał w TOP jedynie 40 - 50%, w przypadku gdy skakał do 120 - 150% nie dochodziło do freezów czy nawet spowolnienia działania serwera).

 

Ilość baz danych obecnie to około 140 sztuk. Większość baz danych nie przekracza nawet 200kB. Tylko niektóre mają 1MB. Strony nigdy nie są otwierane w jednym czasie (jedynym odwiedzającym są Google Boty). Mimo tego, serwer przestawał działać "ot tak".

 

Zwątpiwszy w poprawność rozwiązania cpulimit - usunąłem je, aczkolwiek problem w dalszym ciągu występował. W przypadku większego obciążenia (czas wykonania skryptu dłuższy niż 30 sekund) MySQL zamiast rozpiąć użytkownika - zawieszał się. Problem spotęgował się w dniu dzisiejszym, kiedy to przy niemalże każdym zapytaniu MySQL upada i powoduje freeze systemu (zalogowanie się po SSH jest najzwyczajniej w świecie... niemożliwe). MySQL po tym nie daje się uruchomić. Standardowe /etc/init.d/mysqld restart zwraca informację o tym, że MySQL już pracuje, zaś próba zatrzymania go (killall) zwraca informację, że... nie ma takiego procesu. Próba ponownego instalowania mysql z custombuild'a nie przynosi oczekiwanych rezultatów (brak poprawy). O ile wcześniej pomocny był reboot całego systemu, o tyle w chwili obecnej nie pomaga to, a MySQL zaczyna działać w losowych momentach.

 

Wszelkie moje próby rozwiązania problemu w ramach moich umiejętności spełzły na niczym, dlatego też zwracam się z uprzejmą prośbą o podpowiedzenie co może zostać problemem.

 

Nie będę ukrywał, że moja wiedza z zakresu administracji serwerami dedykowanymi ogranicza się do podstawowych umiejętności, które zdobyłem eksperymentując w syntetycznym środowisku, więc rozwiązywanie bardziej złożonych problemów po prostu nie jest moją mocną stroną.

 

Na forach dotyczących bugów MySQL spotkałem się z opiniami, że jest to najzwyczajniej w świecie problem z MySQL, aczkolwiek dopóki nie mam pewności, nie chcę nic zmieniać.

Edytowano Luty 8, 2012 przez webmaniac (zobacz historię edycji)

[eRIZ 4]

Jaki silnik bazy? Która wersja MySQL? Próbowałeś zdumpować bazy do SQL, wyczyścić dane demona i je ponownie zaimportować?

[webmaniac 0]

Zawartość /etc/my.cnf

[mysqld]
port			= 3306
socket		  = /tmp/mysql.sock
#skip-locking
key_buffer_size = 256M
max_allowed_packet = 1M
table_open_cache = 256
sort_buffer_size = 1M
read_buffer_size = 1M
read_rnd_buffer_size = 4M
myisam_sort_buffer_size = 64M
thread_cache_size = 8
query_cache_size= 16M
# Try number of CPU's*2 for thread_concurrency
thread_concurrency = 4


# Replication Master Server (default)
# binary logging is required for replication
log-bin=mysql-bin

# binary logging format - mixed recommended
binlog_format=mixed

# required unique id between 1 and 2^32 - 1
# defaults to 1 if master-host is not set
# but will not function as a master if omitted
server-id	   = 1

[mysqldump]
quick
max_allowed_packet = 16M

[mysql]
no-auto-rehash
# Remove the next comment character if you are not familiar with SQL
#safe-updates

[myisamchk]
key_buffer_size = 128M
sort_buffer_size = 128M
read_buffer = 2M
write_buffer = 2M

[mysqlhotcopy]
interactive-timeout

 

Jeżeli zaś chodzi o wersję MySQL - zaraz podam szczegóły, tylko się przebiję przez kolejny freeze. mysql5.1:5.1.61

Edytowano Luty 8, 2012 przez webmaniac (zobacz historię edycji)

[Krzysztof Hajd 0]

1) Zrób dump baz danych

2) Wywal wszelkie kompilowane wersje MySQL- nie po to firmy oferują binarne wersje enterprise, byś się pałował z tym, że coś wysiadło. Tak masz przynajmniej kogo objechać

3) Postaw MySQL z paczek albo Percona Server / MariaDB (Warto jak masz bazy InnoDB)

4) Zaimportuj bazy.

5) table_open_cache podbij sobie do 1024-2048. Bufory 1-4M podbij *2. MySQL powinien żwawiej działać.

[xorg 693]

Percona Server

Bardzo ciekawy mod, od siebie mogę polecić

[lukaschemp 27]

Freeze często jest gdy na serwerze zabraknie ramu, bo np. MySQL wykorzystał cały. Sprawdzałeś to?

[devilMedia.pl 26]

Zapewne tak jest. Sprawdź logi i przejrzyj czy killer (oom) nie poubijał procesów. Oznacza to, że za bardzo przedobrzyłeś w swoich ustawieniach MySQL. Ile ten serwer ma pamięci?

[Schizzo 30]

U mnie akurat mysql całego proca żre, więc nie ma na to reguły.

[LANcaster (kotkowicz.pl) 52]

5) table_open_cache podbij sobie do 1024-2048. Bufory 1-4M podbij *2. MySQL powinien żwawiej działać.

 

Oryginalna sugestia. Skąd wiesz ile jest tabel na serwerze? Podbijanie buforów razy dważ wiele nie da. Lepiej dostosować do konkretnych ustawień - chociażby policzyć, ile zajmują pliki indeksów (*.MYI) i ustawić key_buffer_size tak, by wszystkie indeksy zmieściły się w pamięci. Do tego, jeśli używa InnoDB to wypadałoby zmienić defaultowe ustawienia na bardziej dostosowane do serwera, szczególnie:

 

 

innodb_file_per_table

innodb_data_home_dir = /var/lib/mysql

innodb_log_group_home_dir = /var/lib/mysql

innodb_table_locks = 0

innodb_lock_wait_timeout = 10

innodb_log_buffer_size = 8M

innodb_buffer_pool_size = 10GB

innodb_log_files_in_group = 10

innodb_log_file_size = 256M

log_bin_trust_function_creators = 1

innodb_flush_log_at_trx_commit = 2

 

(Te akurat dostosowane są do serwera, którym administruję).

 

Natomiast, miłoby było, gdyby autor wątku poinformował nas chociaż, jaki jest load na serwerze w przypadku zwisu.

[webmaniac 0]

Przepraszam. Temat trochę umknął z racji przygotowań do wdrożenia kolejnej maszyny. Jeżeli chodzi o load serwera - paradoksalnie - zazwyczaj problem występuje po tym jak MySQL klęknie i load spadnie do niemal zera. Czyli w momencie, kiedy próbuje wstać.

 

Co złośliwe - pomimo tego, że MySQL powinno działać na okrągło - jak zdechnie to nawet nie próbuje ponownie wstać. To smutne.

 

Jeżeli chodzi o wykorzystanie RAM - rzadko, bardzo rzadko zdarza się, aby SQL zużywał całą przestrzeń RAM jaka jest mu dostępna. Zazwyczaj down zalicza przy 30 - 40% wykorzystania RAM

Edytowano Kwiecień 29, 2012 przez webmaniac (zobacz historię edycji)