Eksperci naszej firmy, wykonali kilka pomiarów wydajności średnich instancji RDS-a (xlarge), postawionych na procesorach Intel Xeon oraz AMD EPYC™.
Były to najnowsze dostępne wersje procesorów wybranych producentów (r8i / r8a oraz m8i/m8a). Celem była weryfikacja zapowiadanej przed AMD przewagi CPU 8. generacji nad konkurencyjnymi rozwiązaniami dostępnymi na rynku (tak naprawdę jednym dostępnym) przy użyciu go jako procesora obsługującego MS SQL Server.
Co AMD EPYC wnosi do MS SQL Server
Instancje typu R8a są przeznaczone do obciążeń wymagających dużej ilości pamięci, w tym SQL i NoSQL.
AMD EPYC™ 5 generacji pracuje z częstotliwością do 4,5 GHz, co jest korzystne dla SQL Server’a, któremu mocno zależy na wydajności pojedynczego rdzenia dla krótkich transakcji, przepustowości pamięci dla skanów i agregacji oraz skalowania wątków dla równoległych zapytań. architectural designs.
Wymierną korzyścią, która stanowiła cel AMD jest oszczędność – gdy licencja zależy od liczby vCPU: większa praca wykonana na pojedynczym rdzeniu, może pozwolić dobrać mniejszą liczbę licencjonowanych vCPU.
Dane AMD o MS SQL Server opisują ponadto warianty procesorów o wysokim taktowaniu (nawet do 5GHz), dużej liczbie rdzeni i wysokiej przepustowości pamięci.
Opis doświadczenia
Wybraliśmy parami obsługiwane przez RDS dla SQL Server’a instancje r8a/r8i oraz m8a/m8i, zawsze w rozmiarze xlarge.
Pary mają odpowiednio 4 vCPU oraz 32 GB RAM w rodzinie R i 16 GB w rodzinie M. R8a i M8a są oparte na procesorach AMD EPYC™ 5. generacji, a R8i i M8i na Intel Xeon 6; wszystkie cztery klasy są obecnie dostępne dla RDS for SQL Server (lecz nie we wszystkich regionach). Warto zapoznać się z tabelą zgodności silników RDS.
Wykorzystano HammerDB TPROC-C, czyli workload OLTP wzorowany na TPC-C. Dla każdego typu instancji uruchomiono po jednym pięciominutowym przebiegu dla 5, 10, 25, 50, 100 i 200 wirtualnych użytkowników (VU), z dwuminutowym ramp-upem.
NOPM (New Order Per Minute) to liczba nowych zamówień na minutę, a TPM (Transaction Per Minute)- wszystkie transakcje na minutę. Wykres pokazuje NOPM, ponieważ jest bliższy właściwej pracy TPROC-C i łatwiejszy do porównania między przebiegami.
Wyniki dla NOPM prezentuj nastepująco:
Co właściwie można z tego zrozumieć?
Wyraźnie widać, że instancja bazująca na produkcie EPYC™ (ta zoptymalizowana pod przebiegi z dużym poborem pamięci) zaczyna mieć przewagę gdy „pojawia się pole do popisu” – czyli wzrasta ilość użytkowników.
W M8 różnice do 100 VU są niewielkie i mieszczą się w typowej zmienności pojedynczego przebiegu; przy 200 VU oba wyniki są niemal identyczne.
Ten kontrast (R8 <-> M8) jest ważniejszy od jednej liczby „% szybciej”: pokazuje, że charakterystyka całej rodziny i konkretnej konfiguracji RDS-a ma duży wpływ na jakość pracy bazy dla danego scenariuszu. Niewolno przenosić przewagi obserwowanej w R8 na M8 ani z testu syntetycznego bezpośrednio na aplikację produkcyjną.
Wykres TPM potwierdza ten sam kierunek: R8a odjeżdża R8i wraz ze wzrostem liczby VU, natomiast M8a i M8i kończą test niemal remisem. TPM należy czytać jako miarę całkowitej aktywności benchmarku, nie jako niezależną miarę biznesowej liczby zamówień – dlatego NOPM pozostaje głównym miarodajnym wykresem.
Czego jednak stwierdzić nie można
Doświadczone oko szybko zdemaskuje niejaką prowizoryczność przeprowadzonych pomiarów…
Zrobiliśmy domyślny test porównawczy, który korzystał z 100 GB RDS gp3 bez własnego ustawienia IOPS i throughputu.
Dla RDS pod MS SQL Server oznacza to domyślne 3 000 IOPS i 125 MiB/s. W danych, zapis oscyluje w pobliżu 3 000 IOPS, więc storage jest realnym kandydatem na bycie ograniczeniem dla baz w obu testach.
W uzyskanych pomiarach średnie zużycie CPU nie przekracza 30%, ale średnia latencja zapisu odczytana z CloudWatch wynosi w wielu punktach kilkaset milisekund. Na R8i rośnie ona do około 577–627 ms przy 25– 200 VU, podczas gdy R8a utrzymuje około 176–284 ms.
To koreluje z załamaniem NOPM R8i i jest mocniejszym sygnałem ograniczenia logu/I/O niż nasycenia CPU.
Microsoft traktuje konsekwentne czasy takich operacji powyżej około 10–15 ms jako przesłankę do badania wąskiego gardła I/O (diagnostyka I/O w SQL Server).
Podsumowując powyższe – istnieje możliwość optymalizacji parametrów bazy RDS-a tak, żeby pozwolić CPU dać z siebie więcej wydajności i w teorii lepiej przejść powyżej opisane testy. Nie dowodzi to jednak, że Intel byłby słabszy lub silniejszy po wyeliminowaniu ograniczenia I/O.
Dla SQL Server można podnieść na gp3 niezależnie IOPS i throughput, a dla wymagających przewidywalnie niskiej latencji rozważyć io2. Rzetelny kolejny krok to powtórzenie całej macierzy z parametrami storage’u dopasowanymi do zapisu logu i z wait stats SQL Server.
Równie ważna jest druga strona wyniku: w tej minimalnej, wspólnej konfiguracji AMD R8a utrzymał lepszą przepustowość oraz niższą latencję zapisu niż R8i.
Jest to praktyczna korzyść dla zespołu, który zaczyna od prostego i oszczędnego profilu infrastruktury, nie uniwersalny werdykt o CPU.
Prosty przykład możliwej oszczędności przy jednakowej przepustowości
Poniższy model porównawczy dotyczy wyłącznie pary R8 i poziomu 14 497 NOPM, osiągniętego przez pojedyncze db.r8a.xlarge przy 200 VU.
db.r8i.xlarge osiągnął maksymalnie 8 970 NOPM, dlatego do obsłużenia takiego wolumenu należałoby przyjąć dwie instancje Intel – i to tylko w hipotetycznej architekturze, która pozwala podzielić OLTP pomiędzy dwa niezależne primary/shardy. Nie jest to mechanizm automatycznego skalowania pojedynczej bazy SQL Server ani rekomendacja zastępowania większej instancji repliką read-only.
ISTOTNE ZMIENNE:
Założenia finansowe: On-Demand, Single-AZ, eu-central-1 (Frankfurt), SQL Server Standard License
Included, 730 h/miesiąc, bez storage’u, transferu, backupów, Multi-AZ i podatków.
Aktualny cennik AWS dla nowych klas rozdziela koszt infrastruktury (za CPU-h) i licencji (za vCPU-h). Dla xlarge licencjonowane są co najmniej 4 vCPU na instancję; jedna instancja AMD oznacza więc 4 vCPU licencyjne, a dwie instancje Intel – 8 vCPU (cennik RDS for SQL Server)
W tym modelu różnica licencyjna jest równie ważna jak różnica infrastruktury: dwa razy więcej instancji oznacza dwa razy więcej minimalnych, czteroprocesorowych pakietów licencyjnych. W modelu License Included AWS nie kupuje się osobnej licencji Microsoft – jest ona elementem rozliczenia RDS; dla nowych rodzin AWS pokazuje ją jako oddzielny komponent rozliczeniowy (zasady License Included i Optimize CPU).
A gdzie jest Graviton?
AWS Graviton to procesory ARM, nie x86.
Dają bardzo dobry wynik price-performance dla silników i aplikacji dostępnych na ARM/Linux – np. RDS PostgreSQL, MySQL i MariaDB – lecz obecne klasy RDS oparte na Graviton nie obsługują Microsoft SQL Server.
Dla SQL Server wybór praktyczny pozostaje więc x86: AMD lub Intel. Graviton ma sens w osobnej ścieżce modernizacji, gdy silnik, rozszerzenia i aplikacja są gotowe na ARM; nie jest zamiennikiem typu „podmień instancję” dla tego testu (wsparcie klas RDS, wyniki AWS dla RDS na Graviton4).
Podsumowanie
Powyższe liczby nie oznaczają, że AMD zawsze będzie tańszy.
Dla M8 wyniki testu są zbliżone, więc nie ma podstaw, by deklarować podobną oszczędność dla procesorów tych typów
(typ M – ogólnego przeznaczenia). Również po zwiększeniu IOPS/throughputu relacja R8 może się zmienić.
Ten model pokazuje jednocześnie spory potencjał w uzyskaniu realnych korzyści poprzez użycie procesorów typu R8a. Lecz oczywiście przed decyzją produkcyjną należy przeliczyć ją w AWS Pricing Calculator dla wybranej edycji, HA i storage oraz przeprowadzić testy obciążeniowe, bardziej zbliżone do realnych scenariuszy produkcyjnych niż domyślny TPC-C.
db.r8a.xlarge jest sensownym kandydatem do pilotażu dla „pamięciożernych” środowisk RDS for SQL Server, zwłaszcza gdy obecny profil wskazuje na większą pracę na rdzeń lub planowane skalowanie. db.m8a.xlarge nie pokazała w tym teście wyraźnej przewagi nad db.m8i.xlarge, dlatego decyzję między nimi należy oprzeć przede wszystkim na cenie, wymaganej pamięci i powtarzalnym teście aplikacyjnym.