W poprzednim poście pisałem o statystykach udostępnianych przez patch Google i przez Percona Server. Dziś kilka przykładów na wykorzystanie tych danych w praktyce.
czytaj dalej…
Archiwa
Archiwa z daty Październik, 2010Gdy widać, że serwer bazodanowy zaczyna zwalniać, obciążenie procesora jest co raz większe, miło by było aby móc zlokalizować przyczynę takiego stanu rzeczy. W przypadku, gdy stosujemy standardową dystrybucję MySQL a użytkowników w bazie jest więcej niż kilku (i analizowanie bieżących wyników mytop’a czy SHOW PROCESSLIST; już nie wystarcza), w zasadzie jedynym rozwiązaniem jest włączenie pełnego logowania zapytań do slowlogów (long_query_time=0) i a potem wykorzystać magię awk’a/sed’a/perl’a aby posumować czas wykonywania zapytań dla każdego użytkownika. Problem w tym, że po pierwsze, tego typu statystyki są nieprecyzyjne. Jeśli chwilowo serwer został przeciążony, wydłuży się czas wykonywania wszystkich zapytań – nie tylko tych, które przeciążenie spowodowały. Po drugie, logowanie wszystkiego do slowlogu wpływa negatywnie na wydajność serwera – w końcu trzeba te wszystkie logi zapisać na dysku. Po trzecie, jeśli na serwerze jest spory ruch, to i logi będą długie – czas potrzebny na ich obróbkę, a także obciążenie przez ten proces generowane, może być znaczące i w praktyce uniemożliwić wykonywanie tego typu operacji na żądanie – da się je wykonać tylko w zaplanowanym okienku, w nocy, gdy dodatkowe obciążenie serwera nie będzie takim problemem. Czy jest jakieś inne rozwiązanie?
czytaj dalej…
MySQL posiada ciekawy mechanizm, który odpowiednio wykorzystany może znacznie przyspieszyć czas wykonywania się zapytań. Mechanizm ten to cache zapytań (query cache), a sprowadza się on do tego, że MySQL przeznacza pewną ilość pamięci na przechowywanie wyników zapytań. Działa to tak, że do cache trafia informacja o jakie zapytanie chodzi i jaki wynik zwróciło. Każde zapytanie jest sprawdzane pod kontem tego, czy jego wynik nie znajduje się w cache. Jeśli tak jest, wynik jest pobierany i przesyłany do klienta bez konieczności wykonywania całego zapytania. Jeśli nie, zapytanie jest normalnie wykonywane. Co ważne, w standardowej wersji MySQL porównywana jest cała treść zapytania. W efekcie zapytanie:
SELECT /* komentarz */ * FROM tabela WHERE kolumna='optymizacja';
jest innym zapytaniem niż:
SELECT * FROM tabela WHERE kolumna='optymizacja';
pomimo, że różnią się one tylko komentarzem. Zmodyfikowane wersje MySQL (jak na przykład Percona Server) potrafią sobie z komentarzami radzić, usuwając je po prostu przed sprawdzaniem cache. Co jest oczywiste, pobranie wyniku z cache jest rozwiązaniem szybszym niż wykonywanie całego zapytania, wydawałoby się, że zwiększanie query cache jest znakomitym sposobem na poprawę wydajności serwera MySQL. Czy tak jest faktycznie?
czytaj dalej…
Wydawałoby się, że sprawa jest oczywista, ale biorąc pod uwagę ilość pytań z Google dotyczących tego tematu, wygląda na to że nie jest tak do końca. Tak więc dziś szukamy logów MySQL. Jakie są te logi i do czego służą?
Tak jak pisałem w poprzednim poście do przenoszenia informacji o modyfikacjach MySQL stosuje binlogi. Replikacja MySQL może działać w trzech trybach, które przekładają się na to, co do binlogów jest zapisywane – row-based replication (RBR), statement-based replication (SBR) i mieszanka obu trybów. Ustawia się to przy pomocy zmiennej binlog_format, która może przyjąć wartość ROW, STATEMENT i MIXED.
czytaj dalej…
