Generator my.cnf

Generator my.cnf — tuning MySQL i MariaDB

Najważniejszym parametrem wydajności MySQL jest rozmiar bufora InnoDB. Domyślne wartości są bardzo małe (np. 128 MB), przez co baza odwołuje się do dysku znacznie częściej, niż musi.

Kluczowe parametry

Zasady doboru

• innodb_buffer_pool_size — 60–70% RAM na dedykowanym serwerze bazy.
• innodb_flush_log_at_trx_commit — wartość 2 to kompromis między bezpieczeństwem a wydajnością.
• max_connections — nie ustawiaj zbyt wysoko; każde połączenie zajmuje pamięć.
• Po zmianach zrestartuj usługę i obserwuj wolne zapytania.

Jak generator liczy wartości do my.cnf

Generator nie zgaduje — przelicza. Podajesz rozmiar pamięci RAM serwera i podstawowe informacje o obciążeniu, a narzędzie stosuje reguły znane z ręcznego strojenia MySQL i MariaDB: bufor InnoDB dostaje 60–70% pamięci, a reszta zostaje dla systemu operacyjnego, procesów pomocniczych i samej bazy.

Fundamentem jest prosty wzór: innodb_buffer_pool_size mieści się w przedziale od RAM × 0,6 do RAM × 0,7. Dla serwera z 16 GB pamięci (16384 MB) daje to od 9830,4 MB do 11468,8 MB. Każda wartość z tego przedziału jest lepsza niż domyślne 128 MB, które na takiej maszynie zajmuje zaledwie 0,78% RAM — dlatego baza tak często sięga po dysk.

Pozostałe parametry wynikają z tej samej zasady bilansowania pamięci. Połączenia, bufory sesji i tabele tymczasowe muszą się zmieścić w części, która nie trafiła do bufora — dlatego im wyżej ustawisz bufor, tym ostrożniej trzeba podchodzić do liczby połączeń. Generator zwraca komplet ustawień w jednym spójnym zestawie, który można wkleić do sekcji [mysqld].

Przykład: serwer 16 GB RAM krok po kroku

1. Ustal dostępną pamięć: 16 GB to 16384 MB.
2. Policz widełki dla bufora: 16384 × 0,6 = 9830,4 MB oraz 16384 × 0,7 = 11468,8 MB.
3. Wybierz wartość mieszczącą się w przedziale — np. 10240 MB, czyli 10240 / 16384 = 62,5% RAM.
4. Porównaj z domyślnym ustawieniem: 10240 / 128 = 80, czyli bufor będzie 80 razy większy niż standardowe 128 MB.
5. Sprawdź, ile pamięci zostaje systemowi: 16384 − 10240 = 6144 MB na system operacyjny, procesy towarzyszące i bufory połączeń.
6. Zapisz parametry w sekcji [mysqld], zrestartuj usługę i obserwuj wskaźnik Buffer pool hit rate — celem jest wartość powyżej 99%.

Ile pamięci przeznaczyć na bufor przy różnych rozmiarach RAM

Jak używać generatora w praktyce

• Podaj realną pamięć maszyny, nie całego hosta. Jeśli baza działa w kontenerze lub maszynie wirtualnej z limitem, wpisz ten limit — inaczej wyliczony bufor nie zmieści się w dostępnej pamięci.
• Zacznij od dolnej granicy przedziału. Przy 60% zostaje więcej miejsca na bufory połączeń i tabele tymczasowe; jeśli po testach hit rate jest zbyt niski, podnieś wartość w stronę 70%.
• Ustawiaj bufor razem z max_connections. Każde połączenie rezerwuje pamięć na własne bufory, więc wysokie max_connections i bufor na górnej granicy przedziału to proszenie się o swap.
• Traktuj wynik jako punkt startowy. Wklej wygenerowany fragment do [mysqld], uruchom serwer i dopiero po obserwacji wolnych zapytań koryguj wartości.
• Zapisuj, co zmieniłeś. Trzymaj kopię poprzedniego pliku konfiguracyjnego, żeby móc wrócić do działających ustawień, gdy nowe okażą się zbyt agresywne.

Czego generator nie uwzględni

• Rzeczywistego profilu obciążenia. Narzędzie opiera się na rozmiarze RAM, a nie na liczbie zapytań, proporcji odczytów do zapisów ani typie danych — baza z przewagą zapisów potrzebuje innych proporcji niż serwis czytający.
• Pamięci zajętej przez inne procesy. Jeśli na tej samej maszynie działa serwer aplikacji, cache albo silnik wyszukiwania, wolnej pamięci jest mniej, niż wynika z samej wartości RAM.
• Wersji i silnika Storage Engine. Zakresy parametrów mają sens dla InnoDB; tabele MyISAM, Aria czy inne silniki rządzą się własnymi zasadami i nie korzystają z bufora InnoDB.
• Limitów systemu i kontenera. Ograniczenia cgroup, ulimit czy parametrów jądra potrafią sprawić, że formalnie poprawna konfiguracja zostanie zdławiona lub zakończona przez OOM killer.

Najczęstsze pytania