Najlepsze rozwiązania dotyczące optymalnej wydajności
Azure Managed Instance for Apache Cassandra to w pełni zarządzana usługa dla czystych klastrów Apache Cassandra typu open source. Usługa umożliwia również zastępowanie konfiguracji w zależności od konkretnych potrzeb każdego obciążenia, co pozwala na maksymalną elastyczność i kontrolę w razie potrzeby. Ten artykuł zawiera wskazówki dotyczące optymalizowania wydajności.
Optymalna konfiguracja i konfiguracja
Współczynnik replikacji, liczba dysków, liczba węzłów i jednostek SKU
Ponieważ pomoc techniczna platformy Azure trzy strefy dostępności w większości regionów, a wystąpienie zarządzane Cassandra mapuje strefy dostępności na stojaki, zalecamy wybranie klucza partycji o wysokiej kardynalności, aby uniknąć gorących partycji. Aby uzyskać najlepszy poziom niezawodności i odporności na uszkodzenia, zdecydowanie zalecamy skonfigurowanie współczynnika replikacji 3. Zalecamy również określenie wielokrotności współczynnika replikacji jako liczby węzłów, na przykład 3, 6, 9 itd.
Używamy macierzy RAID 0 w liczbie aprowizowana przez Ciebie dysków. Aby uzyskać optymalną liczbę operacji we/wy na sekundę, należy sprawdzić maksymalną liczbę operacji we/wy na sekundę na jednostkę SKU wybraną razem z operacją we/wy na sekundę dysku P30. Na przykład jednostka Standard_DS14_v2 SKU obsługuje 51 200 niebuforowanych operacji we/wy na sekundę, natomiast pojedynczy dysk P30 ma podstawową wydajność 5000 operacji we/wy na sekundę. W związku z tym cztery dyski doprowadziłyby do 20 000 operacji we/wy na sekundę, co jest najwygodniej poniżej limitów maszyny.
Zdecydowanie zalecamy rozbudowane testowanie porównawcze obciążenia względem jednostki SKU i liczby dysków. Testy porównawcze są szczególnie ważne w przypadku jednostek SKU z zaledwie ośmioma rdzeniami. Nasze badania pokazują, że osiem podstawowych procesorów cpu działa tylko w przypadku najmniej wymagających obciążeń, a większość obciążeń wymaga co najmniej 16 rdzeni do wykonania.
Obciążenia analityczne a transakcyjne
Obciążenia transakcyjne zwykle wymagają centrum danych zoptymalizowanego pod kątem małych opóźnień, podczas gdy obciążenia analityczne często używają bardziej złożonych zapytań, co trwa dłużej. W większości przypadków potrzebujesz oddzielnych centrów danych:
- Jedno zoptymalizowane pod kątem małych opóźnień
- Jeden zoptymalizowany pod kątem obciążeń analitycznych
Optymalizowanie pod kątem obciążeń analitycznych
Zalecamy klientom stosowanie następujących cassandra.yaml ustawień dla obciążeń analitycznych (zobacz tutaj , jak zastosować).
Limity czasu
| Value | Ustawienie domyślne wystąpienia zarządzanego bazy danych Cassandra | Zalecenie dotyczące obciążenia analitycznego |
|---|---|---|
| read_request_timeout_in_ms | 5,000 | 10,000 |
| range_request_timeout_in_ms | 10,000 | 20,000 |
| counter_write_request_timeout_in_ms | 5,000 | 10,000 |
| cas_contention_timeout_in_ms | 1,000 | 2000 |
| truncate_request_timeout_in_ms | 60,000 | 120 000 |
| slow_query_log_timeout_in_ms | 500 | 1000 |
| roles_validity_in_ms | 2,000 | 120 000 |
| permissions_validity_in_ms | 2,000 | 120 000 |
Pamięci podręczne
| Value | Ustawienie domyślne wystąpienia zarządzanego bazy danych Cassandra | Zalecenie dotyczące obciążenia analitycznego |
|---|---|---|
| file_cache_size_in_mb | 2,048 | 6144 |
Więcej zaleceń
| Value | Ustawienie domyślne wystąpienia zarządzanego bazy danych Cassandra | Zalecenie dotyczące obciążenia analitycznego |
|---|---|---|
| commitlog_total_space_in_mb | 8,192 | 16,384 |
| column_index_size_in_kb | 64 | 16 |
| compaction_throughput_mb_per_sec | 128 | 256 |
Ustawienia klienta
Zalecamy zwiększenie limitów czasu sterownika klienta Cassandra zgodnie z limitami czasu zastosowanymi na serwerze.
Optymalizacja pod kątem małych opóźnień
Nasze ustawienia domyślne są już odpowiednie dla obciążeń o małych opóźnieniach. Aby zapewnić najlepszą wydajność dla opóźnień końcowych, zdecydowanie zalecamy użycie sterownika klienta obsługującego wykonywanie spekulacyjne i odpowiednio skonfigurowanie klienta. W przypadku sterownika Języka Java w wersji 4 można znaleźć pokaz pokazujący, jak to działa i jak włączyć zasady tutaj.
Monitorowanie szyi butelek wydajności
Wydajność procesora CPU
Podobnie jak w przypadku każdego systemu bazy danych system Cassandra działa najlepiej, jeśli wykorzystanie procesora CPU wynosi około 50% i nigdy nie przekracza 80%. Metryki procesora CPU można wyświetlić na karcie Metryki w obszarze Monitorowanie w portalu:
Napiwek
Aby uzyskać realistyczny widok procesora CPU, dodaj filtr i podziel właściwość za pomocą Usage kind=usage_idlepolecenia . Jeśli ta wartość jest niższa niż 20%, można zastosować dzielenie w celu uzyskania użycia przez wszystkie rodzaje użycia.
Jeśli procesor CPU jest trwale powyżej 80% dla większości węzłów, baza danych staje się przeciążona manifestem w wielu limitach czasu klienta. W tym scenariuszu zalecamy wykonanie następujących akcji:
- skalowanie w pionie w górę do jednostki SKU przy użyciu większej liczby rdzeni procesora CPU (zwłaszcza jeśli rdzenie są tylko 8 lub mniejsze).
- Skalowanie w poziomie przez dodanie większej liczby węzłów (jak wspomniano wcześniej, liczba węzłów powinna być wielokrotną liczbą współczynnika replikacji).
Jeśli procesor CPU jest wysoki tylko dla kilku węzłów, ale niski dla innych, wskazuje gorącą partycję i wymaga dalszej analizy.
Uwaga
Zmiana jednostki SKU jest obsługiwana za pośrednictwem witryny Azure Portal, interfejsu wiersza polecenia platformy Azure i wdrożenia szablonu usługi ARM. Możesz wdrożyć/edytować szablon usługi ARM i zastąpić jednostkę SKU jednym z następujących elementów.
- Standard_E8s_v4
- Standard_E16s_v4
- Standard_E20s_v4
- Standard_E32s_v4
- Standardowa_DS13_v2
- Standardowa_DS14_v2
- Standard_D8s_v4
- Standard_D16s_v4
- Standard_D32s_v4
- Standard_L8s_v3
- Standard_L16s_v3
- Standard_L32s_v3
- Standard_L8as_v3
- Standard_L16as_v3
- Standard_L32as_v3
Pamiętaj, że obecnie nie obsługujemy przejścia między rodzinami jednostek SKU. Na przykład jeśli obecnie posiadasz element Standard_DS13_v2 i interesuje Cię uaktualnienie do większej jednostki SKU, takiej jak Standard_DS14_v2, ta opcja jest niedostępna. Można jednak otworzyć bilet pomocy technicznej, aby poprosić o uaktualnienie do wyższej jednostki SKU.
Wydajność dysku
Usługa jest uruchamiana na dyskach zarządzanych platformy Azure P30, co pozwala na "operacje we/wy na sekundę ze wzrostem liczby operacji we/wy na sekundę". Dokładne monitorowanie jest wymagane, jeśli chodzi o wąskie gardła wydajności związane z dyskiem. W takim przypadku ważne jest przejrzenie metryk liczby operacji we/wy na sekundę:
Jeśli metryki pokazują jedną lub wszystkie poniższe cechy, może to oznaczać, że trzeba przeprowadzić skalowanie w górę.
- Stale wyższe niż lub równe podstawowej operacji we/wy na sekundę (pamiętaj, aby pomnożyć 5000 operacji we/wy na sekundę przez liczbę dysków na węzeł, aby uzyskać liczbę).
- Stale wyższe niż lub równe maksymalnej liczby operacji we/wy na sekundę dozwolonych dla jednostki SKU dla operacji zapisu.
- Jednostka SKU obsługuje magazyn buforowany (pamięć podręczna zapisu i zapisu), a ta liczba jest mniejsza niż liczba operacji we/wy na sekundę z dysków zarządzanych (będzie to górny limit liczby operacji we/wy odczytu na sekundę).
Jeśli zostanie wyświetlony tylko podwyższony poziom liczby operacji we/wy na sekundę dla kilku węzłów, może istnieć gorąca partycja i konieczne jest przejrzenie danych pod kątem potencjalnego niesymetryczności.
Jeśli liczba operacji we/wy na sekundę jest niższa niż obsługiwana przez wybraną jednostkę SKU, ale wyższa lub równa operacji we/wy na sekundę dysku, możesz wykonać następujące akcje:
- Dodaj więcej dysków, aby zwiększyć wydajność. Zwiększenie liczby dysków wymaga zgłoszenia do pomocy technicznej.
- Skalowanie w górę centrów danych przez dodanie kolejnych węzłów.
Jeśli maksymalna liczba operacji we/wy na sekundę jest obsługiwana przez jednostkę SKU, możesz:
- skalowanie w górę do innej jednostki SKU obsługującej większą liczbę operacji we/wy na sekundę.
- Skalowanie w górę centrów danych przez dodanie kolejnych węzłów.
Aby uzyskać więcej informacji, zapoznaj się z tematem Virtual Machine and disk performance (Wydajność maszyny wirtualnej i dysku).
Wydajność sieciowa
W większości przypadków wydajność sieci jest wystarczająca. Jeśli jednak często przesyłasz strumieniowo dane (takie jak częste skalowanie w poziomie w górę/w dół) lub występują ogromne ruchy danych przychodzących/wychodzących, może to stać się problemem. Może być konieczne oszacowanie wydajności sieci jednostki SKU. Na przykład jednostka Standard_DS14_v2 SKU obsługuje 12 000 Mb/s, porównaj je z bajtem/wyjściem w metrykach:
Jeśli widzisz tylko podwyższony poziom uprawnień sieci dla kilku węzłów, może istnieć gorąca partycja i trzeba przejrzeć rozkład danych i/lub wzorce dostępu pod kątem potencjalnego niesymetryczności.
- Skalowanie w pionie w górę do innej jednostki SKU obsługującej większą liczbę operacji we/wy sieci.
- Skalowanie w górę klastra w poziomie przez dodanie większej liczby węzłów.
Zbyt wielu połączonych klientów
Wdrożenia powinny być planowane i aprowidowane w celu obsługi maksymalnej liczby żądań równoległych wymaganych do żądanego opóźnienia aplikacji. W przypadku danego wdrożenia wprowadzenie większego obciążenia do systemu powyżej progu minimalnego zwiększa ogólne opóźnienie. Monitoruj liczbę połączonych klientów, aby upewnić się, że nie przekracza to dopuszczalnych limitów.
Miejsce na dysku
W większości przypadków jest wystarczająca ilość miejsca na dysku, ponieważ wdrożenia domyślne są zoptymalizowane pod kątem liczby operacji we/wy na sekundę, co prowadzi do niskiego wykorzystania dysku. Niemniej jednak zalecamy od czasu do czasu przejrzenie metryk miejsca na dysku. System Cassandra gromadzi dużo dysków, a następnie zmniejsza je po wyzwoleniu kompaktowania. Dlatego ważne jest przejrzenie użycia dysku w dłuższych okresach w celu ustalenia trendów — takich jak kompaktowanie nie może odzyskać miejsca.
Uwaga
Aby zapewnić dostępną przestrzeń do kompaktowania, wykorzystanie dysku powinno być utrzymywane do około 50%.
Jeśli widzisz to zachowanie tylko dla kilku węzłów, może istnieć gorąca partycja i trzeba przejrzeć rozkład danych i/lub wzorce dostępu pod kątem potencjalnego niesymetryczności.
- dodawanie większej liczby dysków, ale należy pamiętać o limitach liczby operacji we/wy na sekundę narzuconych przez jednostkę SKU
- skalowanie w górę klastra w górę
Pamięć JVM
Nasza domyślna formuła przypisuje połowę pamięci maszyny wirtualnej do maszyny wirtualnej JVM z górnym limitem 31 GB — co w większości przypadków jest dobrą równowagą między wydajnością a pamięcią. Niektóre obciążenia, zwłaszcza te, które mają częste operacje odczytu między partycjami lub skanowania zakresów, mogą być kwestionowane.
W większości przypadków pamięć jest odzyskiwane skutecznie przez moduł odśmiecający pamięci Java, ale zwłaszcza jeśli procesor jest często powyżej 80% nie ma wystarczającej liczby cykli procesora CPU dla modułu odśmiecający pamięć. Dlatego wszelkie problemy z wydajnością procesora CPU powinny być rozwiązane przed problemami z pamięcią.
Jeśli wskaźnik myszy procesora CPU znajduje się poniżej 70%, a odzyskiwanie pamięci nie jest możliwe, może być konieczne użycie większej ilości pamięci JVM. Jest to szczególnie przypadek, jeśli korzystasz z jednostki SKU z ograniczoną ilością pamięci. W większości przypadków należy przejrzeć zapytania i ustawienia klienta i zmniejszyć fetch_size je wraz z wybranymi w limit zapytaniu CQL.
Jeśli rzeczywiście potrzebujesz więcej pamięci, możesz:
- Utwórz bilet, aby zwiększyć ustawienia pamięci JVM
- Skalowanie w pionie do jednostki SKU, która ma większą ilość dostępnej pamięci
Nagrobków
Przeprowadzamy naprawy co siedem dni z reaperem, co powoduje usunięcie wierszy, których czas wygaśnięcia wygasł (nazywany "grobowcem"). Niektóre obciążenia często usuwają i widzą ostrzeżenia, takie jak Read 96 live rows and 5035 tombstone cells for query SELECT ...; token <token> (see tombstone_warn_threshold) w dziennikach bazy danych Cassandra, a nawet błędy wskazujące, że zapytanie nie może zostać spełnione z powodu nadmiernych reliktów.
Krótkoterminowe ograniczenie ryzyka, jeśli zapytania nie zostaną spełnione, to zwiększenie tombstone_failure_threshold konfiguracji bazy danych Cassandra z domyślnej wartości 100 000 do wyższej.
Oprócz tego zalecamy przejrzenie czasu wygaśnięcia w przestrzeni kluczy i potencjalnie uruchomienie napraw codziennie w celu wyczyszczenia większej liczby reliktów. Jeśli listy TTL są krótkie, na przykład mniej niż dwa dni, a dane przepływają i są usuwane szybko, zalecamy przejrzenie strategii kompaktowania i faworyzowanie Leveled Compaction Strategy. W niektórych przypadkach takie akcje mogą wskazywać, że wymagany jest przegląd modelu danych.
Ostrzeżenia wsadowe
To ostrzeżenie może wystąpić w dziennikach CassandraLogs i potencjalnie powiązanych błędach:
Batch for [<table>] is of size 6.740KiB, exceeding specified threshold of 5.000KiB by 1.740KiB.
W takim przypadku należy przejrzeć zapytania, aby pozostać poniżej zalecanego rozmiaru partii. W rzadkich przypadkach i jako krótkoterminowe środki zaradcze można zwiększyć batch_size_fail_threshold_in_kb w konfiguracji Cassandra z wartości domyślnej 50 do wyższej wartości.
Ostrzeżenie o dużej partycji
To ostrzeżenie może wystąpić w pliku CassandraLogs:
Writing large partition <table> (105.426MiB) to sstable <file>
Wskazuje to problem w modelu danych. Oto artykuł dotyczący przepełnienia stosu, który zawiera bardziej szczegółowe informacje. Może to spowodować poważne problemy z wydajnością i należy je rozwiązać.
Wyspecjalizowane optymalizacje
Kompresja
System Cassandra umożliwia wybór odpowiedniego algorytmu kompresji podczas tworzenia tabeli (zobacz Kompresja) Wartość domyślna to LZ4, która jest doskonała dla przepływności i procesora CPU, ale zużywa więcej miejsca na dysku. Użycie rozwiązania Zstd (Cassandra 4.0 i nowszych) pozwala zaoszczędzić około 12% miejsca przy minimalnym nakładzie procesora CPU.
Optymalizowanie miejsca stertowania memtable
Domyślną wartością jest użycie stosu JVM 1/4 dla memtable_heap_space w pliku cassandra.yaml. W przypadku aplikacji zorientowanej na zapis i/lub jednostek SKU z małą ilością pamięci może to prowadzić do częstego opróżniania i fragmentowanych tabel sstable, co wymaga większej kompaktowania. W takich przypadkach zwiększenie wartości do co najmniej 4048 może być korzystne, ale wymaga starannego porównywania porównawczego, aby upewnić się, że nie ma to wpływu na inne operacje (na przykład odczyty).
Następne kroki
W tym artykule przedstawiono najlepsze rozwiązania dotyczące optymalnej wydajności. Teraz możesz rozpocząć pracę z klastrem: