Tabela parametrów instancji

Czytanie klasy instancji jako zestawu wartości parametrów

Klasa instancji zarządzanej bazy wygląda jak fakt o dwóch kolumnach — tyle vCPU, tyle pamięci — ale w istocie jest zestawem decyzji już za ciebie podjętych. Sama liczba pamięci ustala sufit połączeń, bufor cache i obraz świata, jaki ma planer. Ta tabela pokazuje każdą instancję obok wartości parametrów wynikających z jej pamięci, żebyś mógł czytać klasę jako konfigurację, którą naprawdę jest.

Jak to działa

• Wypisuje każdą klasę instancji z katalogu wybranej chmury, od najmniejszej do największej.
• Pokazuje pamięć na vCPU — najszybszy sposób odróżnienia klasy ogólnego przeznaczenia od zoptymalizowanej pod pamięć.
• Podaje max_connections dla instancji, policzone z opublikowanej reguły dostawcy i wybranego silnika.
• Pokazuje shared_buffers albo innodb_buffer_pool_size oraz effective_cache_size, wyprowadzone z domyślnych wyrażeń RDS.

kolumny i ich źródła
  vCPU, pamięć     tabela klas instancji dostawcy
  GiB / vCPU       pamięć dzielona przez vCPU
  max_connections  opublikowana reguła dostawcy dla wybranego silnika
  shared_buffers        25% pamięci   (PostgreSQL)
  innodb_buffer_pool    75% pamięci   (MySQL)
  effective_cache_size  75% pamięci   (podpowiedź dla planera)

Przykład z liczbami

Jedna klasa instancji, db.m5.2xlarge z 8 vCPU i 32 GiB, odczytana na obu silnikach.

1. pamięć na vCPU = 32 ÷ 8 = 4 GiB, proporcja ogólnego przeznaczenia
2. PostgreSQL: około 3324 połączeń, shared_buffers 8 GiB, effective_cache_size 24 GiB
3. MySQL: około 2518 połączeń, innodb_buffer_pool_size 24 GiB
4. ten sam sprzęt, dwa silniki, a przydział bufora różni się trzykrotnie

PostgreSQL zatrzymuje dla siebie 25% i resztę zostawia cache'owi systemu; MySQL zabiera 75% dla InnoDB, bo na tym cache'u się nie opiera. Żadne z tego nie jest wyborem strojenia, który podejmujesz od niechcenia — oba są konsekwencją wyboru klasy i dlatego ta sama instancja zachowuje się inaczej pod każdym z silników.

Jak czytać wynik

• Pamięć na vCPU mówi, do czego klasa służy. Około 2 GiB na vCPU to profil obliczeniowy, 4 GiB ogólnego przeznaczenia, 8 GiB i więcej to optymalizacja pod pamięć — klasy r w AWS, seria E w Azure. Dla bazy wyższe proporcje zwykle są korzystniejsze, bo pamięć kupuje i cache, i zapas połączeń.
• Azure B1ms to jedyny wiersz łamiący własny wzorzec: 50 połączeń tam, gdzie reguła na GiB przewidywałaby znacznie więcej. Ta tabela odtwarza opublikowane wartości Azure, a nie dopasowuje krzywą, więc ta anomalia przetrwała, zamiast zostać wygładzona.
• Klasa t w AWS i seria B w Azure są typu burstable. Zbierają kredyty CPU w bezczynności i dławią, gdy kredyty się skończą, co czyni je świetnymi do dewelopmentu i słabymi pod stałe obciążenie produkcyjne — tabela pokazuje ich parametry, a nie to zastrzeżenie, więc pamiętaj o nim, gdy najmniejszym dopasowaniem okaże się któraś z nich.
• Wpisy Cloud SQL to popularne kształty niestandardowe, a nie wyczerpujący katalog, bo Cloud SQL pozwala zamówić niemal dowolną kombinację vCPU i pamięci. Traktuj tę kolumnę jako reprezentatywną.
• Te wartości parametrów to ustawienia domyślne, z jakimi instancja startuje, a nie limity. Wszystkie trzy chmury pozwalają je nadpisać przez grupę parametrów albo flagę, a wzory na połączenia to tylko wartości domyślne — zajrzyj do kalkulatora maksymalnych połączeń, żeby zobaczyć, ile kosztuje ich zmiana.

Częste pytania

Dlaczego max_connections zmienia się po przełączeniu silnika?

Bo każdy silnik ma własny dzielnik we wzorze dostawcy. W AWS PostgreSQL dzieli dostępną pamięć przez około 9,5 MB na połączenie, a MySQL przez około 12,6 MB, więc ta sama instancja daje mniej połączeń MySQL. MariaDB od 10.5 używa jeszcze innego dzielnika.

Czy więcej pamięci na vCPU zawsze jest lepsze dla bazy?

Zwykle tak, do momentu, gdy zbiór roboczy zmieści się w pamięci. Gdy dane dotykane przez zapytania są już w cache'u, dokładanie pamięci przestaje kupować szybkość i kupuje tylko zapas połączeń. Jeśli twój zbiór jest mały, a zapytania obciążają CPU — dużo sortowania, agregacji albo przetwarzania JSON — lepsza bywa niższa proporcja z większą liczbą rdzeni.

Czy mogę zmienić te wartości po uruchomieniu?

Tak: przez grupę parametrów w RDS, parametry serwera w Azure albo flagi bazy w Cloud SQL. Część działa od razu, część wymaga restartu — shared_buffers i innodb_buffer_pool_size alokują się przy starcie, więc należą do tej drugiej kategorii. Pokazane tu wartości domyślne to rozsądne punkty wyjścia i warto mieć powód, by je nadpisać.

Źródła

• Amazon RDS — klasy instancji
• Azure Database for PostgreSQL — limity
• Cloud SQL for PostgreSQL — flagi