Jak dostroić MySQL do dużego obciążenia InnoDB?

Zakładając produkcyjny system OLTP z głównie tabelami InnoDB

• Jakie są typowe objawy źle skonfigurowanego / źle skonfigurowanego systemu?
• Jakie parametry konfiguracyjne najczęściej zmieniasz w stosunku do ich wartości domyślnych?
• Jak dostrzegasz potencjalne wąskie gardła, zanim pojawi się problem?
• Jak rozpoznajesz i rozwiązujesz aktywne problemy?

statusDocenione zostaną wszelkie anegdoty wyszczególniające określone zmienne i diagnostykę.

Oto dobry artykuł na temat strojenia InnoDB od Jenny Chen Sun - dużo bloguje na temat MySQL, niektóre z nich są specyficzne dla Solaris (np. Za pomocą DTrace ), ale cały blog jest pełen ciekawych ciekawostek.

Co ciekawe, w MySQL 5.5 możesz teraz mieć wiele pul buforów innodb.

Parametry, na których ci zależy

• innodb_buffer_pool_instances (domyślnie 1)
• innodb_buffer_pool_size (domyślnie 1G)

Za około miesiąc jestem gotów zaimplementować 112 pul buforów innodb dla klienta. Dam ci znać, jak poszło.

AKTUALIZACJA 27.02.2011 21:57 EDT

Dowiedziałem się, że maksymalna wartość innodb_buffer_pool_instances to 64. Zdecydowałem się skonfigurować 144 GB, więc ustawiłem innodb_buffer_pool_instances na 18 i innodb_buffer_pool_size na 8. Aktualnie ładuję serwer z 450 GB

AKTUALIZACJA 28.04.2011 13:44 EDT

Wypróbowałem wiele pul buforów InnoDB. Zbyt wiele wątków blokowało i rywalizowało. Zmieniłem na pojedynczą pulę buforów o pojemności 162 GB + ustawienie read_io_threads i write_io_threads na 64 (maksymalna wartość). To działało o wiele lepiej.

AKTUALIZACJA 2012-07-03 17:27 EDT

Nauczyłem się czegoś niesamowitego o MySQL. Jeśli przydzielisz pojedynczą monolityczną pulę buforów InnoDB, która jest większa niż całkowita liczba zainstalowanych urządzeń podzielona przez liczbę fizycznych procesorów , zachęcisz system operacyjny do regularnej wymiany pamięci z powodu pełnej puli buforów InnoDB. Opcja MySQL 5.5 znana jako innodb_buffer_pool_instances może być używana do podziału puli buforów. Wczoraj odpowiednio zaimplementowałem to dla klienta, o którym wspomniałem w zeszłym roku. Nadal mam 162 GB na pulę buforów klienta. Ustawiłem opcję innodb_buffer_pool_instances na serwerze na 2, ponieważ każdy serwer DB jest podwójny hexacore. Myślałem o ustawieniu go na 12, ale potem kolega pokazał mi blog od Jeremy'ego Cole'a na MySQL i Swappiness. Po przeczytaniu wprowadzam go w życie natychmiast dla mojego klienta. Uruchomiłem to polecenie

numactl --hardware

Widziałem mapowanie 192 GB pamięci RAM serwera jako 96 GB na każdy rdzeń fizyczny. Dlatego ustawiłem innodb_buffer_pool_instances na 2. Rzeczy wyglądają teraz dobrze. Zaktualizuję moją odpowiedź, aby zobaczyć, jak wpływa to na zamianę pamięci dla kolejnych 2 miesięcy.

Możesz zapoznać się z następującymi zasobami:

• FAQ najlepszych praktyk
• Ręcznie: strojenie parametrów serwera
• Ręcznie: strojenie InnoDB
• Starsza lista ważnych zmiennych.

Najpierw zwiększ domyślną wielkość puli buforów InnoDB w pliku my.cnf (domyślnie 8 MB)

Prawdopodobnie powinieneś ustawić to na 75% swojego rozmiaru pamięci RAM (ogólnie)

Jakie parametry konfiguracyjne najczęściej zmieniasz w stosunku do ich wartości domyślnych?

konfiguracja pamięci