Nie bać.

Percona Sever jest w zasadzie w pełni kompatybilny z Oraclowym MySQL. Jest co prawda kilka zmian, które skutkują brakiem binarnej kompatybilności pomiędzy XtraDB a InnoDB, ale najpierw trzeba świadomie włączyć to w konfiguracji. Przez trzy lata stosowania ich patchy nie natknąłem się na buga, który nie miałby przyczyny w kodzie pochodzącym z MySQL i który w oryginalnym MySQL by nie występował. Wydajność Percona Server (oczywiście głównie w zakresie InnoDB, bo MyISAM nie jest przez nich ruszany) jest wyższa niż odpowiedniej wersji MySQL wprost z Oracle. Do tego dochodzi logowanie znacznie większej ilości informacji o zapytaniach (dodatkowe info trafia do slowlogów), przez co znacznie łatwiej jest znaleźć przyczynę problemów, zidentyfikować kiepskie zapytania i tak dalej. Tak jak wspominają, Percona Server udostępnia także dokładne statystyki zużycia zasobów przez poszczególnych użytkowników na serwerze, co w środowisku w jakiejkolwiek formie współdzielonym jest ogromnym ułatwieniem dla administratora.
Podsumowując, jeśli masz superusera to dodatkowe statystyki mogą Ci się przydać. Jeśli używasz InnoDB, wydajność powinna być lepsza. Jeśli używasz MyISAM, też powinieneś zyskać - część optymalizacji kodu została także przeprowadzona w kodzie samego MySQL.

ToFFiK, o 08 sierpień 2011 - 01:44, powiedział:

Nie wiem do końca czy na pewno o taki efekt Ci chodzi, ale może to coś pomoże:

create table tab (xxx int);
insert into tab values ('20');

delimiter //
create procedure procedura()
begin
declare a int;
select xxx into a from tab;
if a > 0 then set a = a-1;
end if;
update tab set xxx=a;
end//
delimiter ;

mysql> select * from tab\G
*************************** 1. row ***************************
xxx: 20
1 row in set (0.00 sec)

mysql> call procedura;
Query OK, 1 row affected (0.00 sec)

mysql> select * from tab\G
*************************** 1. row ***************************
xxx: 19
1 row in set (0.00 sec)

Czyli w skrócie, tworzysz procedurę składowaną, która po wywołaniu sprawdza czy wartość w kolumnie xxx w tabeli tab jest większa niż 0. Jeśli tak, zmniejsza ją o 1. Oczywiście Ty prawdopodobnie będziesz musiał to trochę rozbudować (jakieś WHERE, ewentualne dodatkowe warunki - zależy co tak na prawdę potrzebujesz zrobić i na ilu rekordach). Przykład działa tylko dla jednego rekordu w tabeli, jeśli SELECT zwróci Ci więcej wyników, MySQL będzie krzyczał że nie wie co podstawić do zmiennej.

Możesz to też zrobić bez procedury, przy pomocy zmiennych:

mysql> select xxx into @a from tab;
Query OK, 1 row affected (0.00 sec)

mysql> update tab set xxx=
	-> case
	-> when @a>0 then @a-1
	-> end;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

Czyli do zmiennej @a pobierasz wynik SELECTa (tu też pewnie trzeba będzie jakieś WHERE dodać, tak żebyś pobierał tylko jeden rekord) a następnie robisz UPDATE z odpowiednim warunkiem.

krdc.pl, o 22 lipiec 2011 - 08:11, powiedział:

Heh... Mamy coś takiego:

Variables to adjust:
*** MySQL's maximum memory usage is dangerously high ***
*** Add RAM before increasing MySQL buffer variables ***

Na tym komunikacie powinno się zakończyć działanie skryptu. Po co mieszać dalej? Mieszanie to, swoją drogą, jest skuteczne, bo niektórzy zignorują to ostrzeżenie i wprowadzą proponowane zmiany.

Z resztą, nawet zakładając że z pamięcią jest ok, to propozycja podniesienia join_buffer_size do tak wysokich wartości jest zła. Zauważ, że podane jest to jako alternatywa: >1.0G, or always use indexes with joins. Czyli to, albo to. Pewnie że dobrze by było, żeby dokładnie przeanalizować zapytania. Tyle że prostsze jest oczywiście podbicie cyferek w my.cnf i to właśnie zrobi większość użytkowników.

Join buffer to pamięć, która jest alokowana per JOIN. Czyli, w obrębie jednego połączenia, jeśli wykonamy SELECTa z JOINem siedmiu tabel, to zaalokowane może zostać 7GB pamięci. Można o tym przeczytać choćby w oficjalnej dokumentacji MySQL. Można tam także przeczytać, że stosowanie dużych wartości dla globalnej zmiennej join_buffer_size skutkować może spadkiem wydajności ze względu na czas potrzebny do zaalokowania dużej ilości pamięci. Sugerują żeby tą zmienną podbijać tylko wtedy, gdy to jest potrzebne - na poziomie sesji, świadomie, gdy wiemy że wykonywać będziemy jakieś duże JOINy.

W necie, na MySQL Performance Blog konkretnie, można znaleźć informacje na temat działania tego mechanizmu na poziomie kodu źródłowego MySQL. Wynika z nich że nie tyle może zostać zaalokowane, co zawsze zostanie. Zakładając, że pamięci wystarczy. Jeśli system zaalokować nie pozwoli, to JOIN z bufora korzystać nie będzie. Cóż, nie wnikałem w to tak głęboko, w końcu oznajmiono mi że traktuję MySQL po łebkach, więc się staram dostosować Sprawdziłem tylko czy odpowiedni kod nie zmienił się między 5.1.47 a 5.1.57. Nie zmienił się.

Wyobraź sobie co się stanie, jeśli mamy serwer z 8GB RAM, ustawimy join_buffer_size na 1GB, zrobimy JOINa na siedem tabel a pamięci będzie na tyle, że te 7GB uda się zaalokować i faktycznie zostanie wykorzystane. Zużycie pamięci skacze z kilkuset MB na prawie 8GB. Cache dyskowy znika, dyski się rozkręcają, serwer przycina. Oczywiście, to jest najgorszy scenariusz. Normalnie po prostu albo bufor nie zostanie zaalokowany, bo pamięci braknie, albo siądzie wydajność bo za każdym razem trzeba alokować gigabajty pamięci, podczas gdy wykorzystywane są tylko megabajty.

bellerofont, o 22 lipiec 2011 - 00:37, powiedział:

Ja natomiast bardzo Cię proszę żebyś się odniósł do konkretów, a nie pisał tego typu ogólniki. Z czym konkretnie się nie zgadzasz? Chętnie się dowiem gdzie błądzę.

@kafi

Ok, tylko problem z tym, że tego typu sugestia jest zła. Ile można podbijać join_buffer_size? W pierwszym przypadku MySQL mógł zaalokować 400GB pamięci przy prawdopodobnie 8GB na serwerze. Oczywiście, to jest worst case scenario przy wykorzystaniu wszystkich 800 połączeń, ale dla mnie już to jest za dużo.

Pierwsze co to trzeba zrobić to przeglądnąć zapytania i sprawdzić dlaczego JOINy nie korzystają z indeksów. Może tak być, że faktycznie nie da się nic z tym zrobić. Zazwyczaj jednak okazuje się, że to problem po stronie zapytania i nie rozwiąże się go przez zmiany w konfiguracji a tylko przez dodanie indeksów lub przepisanie zapytania. Tak, wiem że w wyniku skrypt pisze o indeksach. Tylko że nadal uważa dalsze podbijanie konfiguracji za coś poprawnego.

Na początek chciałbym zapytać się o jedną rzecz. W czym w ogóle jest problem? Brakuje procesora? Brakuje pamięci? Dysk jest przeciążony?

Jeśli chodzi o podesłane przez Ciebie wyniki z mysqltunera, to rzeczywiście, jak Blueman zauważył, w drugim przypadku serwer działał za krótko w porównaniu z tym co zaleca skrypt. To raz.

Dwa, wyrzuć mysqltunera jak najdalej i już nigdy go nie używaj. Do tej pory miałem stosunek trochę ambiwalentny co do zwracanych przez niego wyników. Sam go nie stosowałem, ale sądziłem że to nic strasznego nie jest. Po Twoich postach wiem, że nie miałem racji. Zwróć uwagę na dwa elementy:

Przed Twoimi zmianami w konfiguracji:
[!!] Maximum possible memory usage: 408.0G (5228% of installed RAM)

Po Twoich zmianach:
[!!] Maximum possible memory usage: 808.1G (10355% of installed RAM)

W skrócie, skrypt zaproponował Ci zmiany znacznie zwiększające możliwość wywalenia całego serwera w kosmos. O co chodzi? Po zmianach MySQL może zaalokować dwukrotnie więcej pamięci (800GB) niż przed zmianami. Nie że poprzednia konfiguracja była bezpieczna - także istniała możliwość zabicia serwera przez brak pamięci. Różnica jest taka, że po zmianach wystarczy do tego mniejsza liczba połączeń.

Faktu uznania za OK czegoś takiego:
[OK] Key buffer size / total MyISAM indexes: 32.0M/403.6M

i nie zasugerowania że może jednak te indeksy w pamięci upchnąć, pozwolę sobie nie komentować.

Nie rozumiem też dlaczego miałbyś zwiększać w nieskończoność join_buffer_size. Trzeba na zapytania popatrzeć i sprawdzić dlaczego po pięciu minutach masz 111 JOINów opartych na skanie tabeli, a nie podbijać zmienne w konfigu.

Zapraszam Cię do lektury dwóch postów z mojego bloga. Pierwszy opisuje sposób zebrania informacji o systemie i MySQL w taki sposób, który umożliwia powiedzenie czegokolwiek na temat tego, co serwerowi dolega:

http://blog.ksiazek....serwerem-mysql/

Drugi post wyjaśnia dlaczego "optymalizacja MySQL" =/= zmiany w konfiguracji sugerowane przez jakikolwiek automat:

http://blog.ksiazek....iguracja-mysql/

Tak żeby było wszystko jasne i żebyśmy się dobrze zrozumieli, to dodam tylko że chętnie Ci pomogę w ustaleniu co jest nie tak. Konieczne jest tylko abyś napisał w czym jest problem i podesłał informacje o których pisałem na blogu. Bez tego wiele nie będę w stanie pomóc.