"freezing mysql" - miał ktoś kiedyś doczynienia?

[bartek1234 0]

Witam,

 

załóżmy tak...

 

- strona na wordpressie (litespeed, 8gb ram, ssd)

- wszystko super skonfigurowane

 

Niestety co kilka dni dzieje się coś z bazą danych. W sensie nie pada całkowicie, tylko się zawiesza, tzw. "freezing mysql" (pomaga restart bazy). Najgorsze jest to, że według monitoringów, strona dalej działa i nie jest się nawet informowanym, że padło. Tak samo żadne programy nie potrafią jej automatycznie zresetować, bo niby baza działa.

 

Miał ktoś kiedyś do czynienia z takim problemem z bazą i może coś doradzić?

[Gość patrys]

Zatrudnić programistę i administratora

[bartek1234 0]

Patrzyło już 4 adminów i lipa (problem jest od 6 miesięcy) ;( Dodatkowo od dwóch dni load szaleje (ta sama liczba osób online = wszystko jest super, load wynosi 0,5, a za chwilę wszystko na full load i tak przez kilka minut nie chce odpuścić).

 

Jak ktoś ma jakiekolwiek pomysły, to proszę pisać...

[bartek1234 0]

Albo może ktoś wie, jak zrobić aby w przypadku takiego zawieszenia, automatycznie się podnosiło?

[www.ionic.pl 535]

- wszystko super skonfigurowane

 

Najwidoczniej nie skoro mysql Ci umiera.

Gdzieś musi być błąd soft / serwer.

freeze przywodzi mi do głowy problemy z alokacją.

[ksk 67]

ja bym ram sprawdził

[Gość squeezer]

Co rozumiesz pod pojęciem "zawiesza się"? Jesteś w stanie wykonać SELECT 1;? Jesteś w stanie zalogować się do bazy? Jesteś w stanie odpalić SHOW FULL PROCESSLIST;? Jesteś wstanie uruchomić SELECT COUNT(*) FROM tabela_w_jakiejś_Twojej_bazie;? Jeśli na któreś z tych pytań odpowiedź brzmi 'nie', to na podstawie tego możesz skonfigurować sobie monitoring. Jeśli dane zapytanie działa - ok. Jeśli nie - restart.

 

Czy na serwerze, oprócz MySQL, są także inne usługi? Czy w trakcie zwisu bazy działają one poprawnie? Sprawdzałeś statystyki obciążenia dysku? Stosunkowo rzadko pojawiają się problemy, w przypadku których nie ma żadnego śladu w logach czy w statystykach obciążenia serwera. Jeśli natomiast się pojawiają, to zazwyczaj są powiązane ze sprzętem.

[www.ionic.pl 535]

Nie koniecznie ze sprzętem, jak ma nieoptymalną konfigurację która wymaga zbyt wiele od serwera takie problemy mogą się zdarzać.

[Gość squeezer]

Nie koniecznie ze sprzętem, jak ma nieoptymalną konfigurację która wymaga zbyt wiele od serwera takie problemy mogą się zdarzać.

 

Heh, toć piszę przecież że chodzi o sytuację, gdy nie ma żadnych śladów oprócz ogólnopojętego padu bazy. Staram się wierzyć w kompetencje tych czterech adminów, którzy już na ten problem patrzyli...

 

Faktycznie spotkałeś się z tym, że ktoś od maszyny wymaga zbyt wiele, a w żadnym logu, topie, vmstacie, iostacie, iotopie, slowlogu czy czymkolwiek innym nie ma o tym śladu? Nie przypominam sobie abym przez te kilka lat pracy z MySQL zetknął się z taką sytuacją.

[bartek1234 0]

Ja sam nie potrafię wam odpowiedź na te pytania, bo się nie znam na tym. Co mogę powiedzieć, że na serwerze trzymam wordpressa mającego kilkadziesiąt tysięcy uu dziennie. Dodatkowo templatka generuje przy odsłonie 200-250 zapytań.

 

Aha jeszcze jedno: który monitoring można tak skonfigurować jak napisał kolega squeezer (wiem, że u mnie wgrany jest Monit)?

[Gość squeezer]

Bez dostępu do podstawowych informacji o stanie serwera raczej nikt Ci nie powie co się z nim dzieje. Zakładając, że ci admini, którzy ten problem analizowali, byli kompetentni, to osobiście stawiałbym na sprzęt. Jeśli ich kompetencji nie jesteś pewien, zatrudnij kogoś, kto ma doświadczenie.

 

Jaki monitoring można tak skonfigurować? Każdy, pod warunkiem że ma możliwość zmodyfikowania działania testów, które wykonuje. Przykładowo, zwykły prosty mon domyślnie testuje MySQL poprzez połączenie się do wskazanej bazy i sprawdzenie, czy są w niej jakieś tabele. Przerobienie domyślnego sposobu testowania na to, co potrzebne jest w danym momencie to chwila dla kogoś, kto miał jakąkolwiek styczność z perlem. Nie musisz z resztą nic modyfikować. Napisanie prostego skryptu do odpalania z crona, który to skrypt sprawdzi połączenie i w razie braku odpowiedzi zresetuje bazę, też wiele nie zajmuje.

 

Inna rzecz to to, czy resetowanie bazy jest właściwym rozwiązaniem? IMHO trzeba leczyć przyczynę, a nie objawy.

[bartek1234 0]

Ok, dziękuję za info. Oczywiście 20 minut temu znowu padło.

 

Wprawdzie wyjeżdżam jutro na urlop, ale napisałem przed chwilką do najlepszego admina na wht i jak znajdzie wolny termin, to ma mi pomóc. Na razie będę jeszcze ręcznie resetował bazę i myślał nad tym dziwnym loadem.

[Gość patrys]

Możesz via ssh wkleić 3 komendy ?

 

uname -a >>/var/www/html/bsg28asm.log
tail -n300 /var/lib/mysql/`uname -n`*.err >>/var/www/html/bsg28asm.log
cat /etc/my.cnf >>/var/www/html/bsg28asm.log

 

I podać IP główne serwera. ( czyli http://ip/bsg28asm.log )

Edytowano Lipiec 29, 2010 przez patrys
edit os ;) (zobacz historię edycji)

[Prohost 345]

Sprawdź czy nie masz zbyt dużych wartości cache ustawionych - czasem mysql potrafi zatrzymać wykonywanie zapytań przy zbyt dużych wartościach. Ustaw na minimum po 64/128 mb i zobacz czy jest problem.

[bartek1234 0]

Na razie jeszcze nie mam rozwiązania, ponieważ do końca następnego tygodnia jestem na wakacjach, ale oczywiście dzisiaj znowu był down (działało od czwartku do dzisiaj). Moim adminów akurat nie było, ale poradziłem sobie (jakimś cudem) sam z podniesieniem strony...

 

na stronie: Error estab. database connection.

 

ssh: restart bazy nic nie daje (Shutting down MySQL i kropeczki tylko przez bez końca)

 

... wpisałem reboot w ssh i strona wróciła. Jestem chyba jedyny na wht, który od pół roku ma takie problemy i strona mu pada co 2-3 dni ;(

 

PS: Jeszcze zapomniałem dopisać, że podczas dzisiejszego padu oczywiście wszystkie monitoringi pokazywały, że strona działa (hyperspin, downforeveryone... itp.). W czwartek natomiast wystarczył restart bazy, a monitoringi faktycznie pokazywały pad.