Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
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. Ta funkcja umożliwia 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 warstw produktów
Platforma Azure obsługuje trzy strefy dostępności w większości regionów. Instancja zarządzana platformy Azure dla usługi Apache Cassandra odpowiada strefom dostępności w stosunku do stojaków. 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 użyj wartości 3, 6, 9 itp.
Platforma Azure używa macierzy RAID 0 nad liczbą dysków, które aprowizujesz. Aby uzyskać optymalną liczbę operacji wejścia/wyjścia na sekundę (IOPS), sprawdź maksymalną wartość IOPS na poziomie produktu, który wybrałeś, oraz IOPS dysku P30. Na przykład Standard_DS14_v2 warstwa produktu obsługuje 51 200 niezbuforowanych operacji wejścia/wyjścia na sekundę. Pojedynczy dysk P30 ma podstawową wydajność 5 000 IOPS. Cztery dyski prowadzą do 20 000 IOPS, co jest poniżej limitów maszyny.
Zdecydowanie zalecamy szeroko zakrojone testy porównawcze obciążeń względem warstwy produktu i liczby dysków. Testy porównawcze są szczególnie ważne w przypadku poziomów produktów mających tylko osiem rdzeni. Nasze badania pokazują, że procesory ośmiordzeniowe są odpowiednie tylko dla najmniej wymagających zadań. Większość obciążeń wymaga co najmniej 16 rdzeni do prawidłowego działania.
Obciążenia analityczne a transakcyjne
Obciążenia transakcyjne zwykle wymagają centrum danych zoptymalizowanego pod kątem małych opóźnień. Obciążenia analityczne często używają bardziej złożonych zapytań, co trwa dłużej. W większości przypadków potrzebne są oddzielne centra 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 zastosowanie następujących cassandra.yaml ustawień dla obciążeń analitycznych. Aby uzyskać więcej informacji na temat sposobu stosowania tych ustawień, zobacz Aktualizowanie konfiguracji bazy danych Cassandra.
Limity czasu
| Wartość | Domyślna wartość Cassandra MI | 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 |
1000 | 2000 |
truncate_request_timeout_in_ms |
60 000 | 120 000 |
slow_query_log_timeout_in_ms |
500 | 1000 |
roles_validity_in_ms |
2000 | 120 000 |
permissions_validity_in_ms |
2000 | 120 000 |
Pamięci podręczne
| Wartość | Domyślna wartość Cassandra MI | Zalecenie dotyczące obciążenia analitycznego |
|---|---|---|
file_cache_size_in_mb |
2,048 | 6144 |
Więcej zaleceń
| Wartość | Domyślna wartość Cassandra MI | 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 limitu czasu sterownika klienta Cassandra zgodnie z limitami czasu zastosowanymi na serwerze.
Optymalizowanie 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 odpowiednie skonfigurowanie klienta. W przypadku sterownika Java V4 demonstracja ilustruje działanie tego procesu i sposób włączania polityki w tym przykładzie.
Monitorowanie wąskich gardeł 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%. Aby wyświetlić metryki procesora CPU, w witrynie Azure Portal w sekcji Monitorowanie otwórz kartę Metryki .
Aby uzyskać rzeczywisty widok CPU, dodaj filtr i użyj znacznika Usage kind=usage_idle do podzielenia właściwości. Jeśli ta wartość jest niższa niż 20%, zastosuj 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, co manifestuje się w wielu limitach czasu klienta. W tym scenariuszu zalecamy wykonanie następujących akcji:
- Skalowanie pionowe na poziom produktu z większą liczbą rdzeni procesora, zwłaszcza jeśli jest ich 8 lub mniej.
- Skaluj poziomo, dodając więcej węzłów. Jak wspomniano wcześniej, liczba węzłów powinna być wielokrotną liczbą współczynnika replikacji.
Jeśli użycie CPU jest wysokie tylko dla kilku węzłów, ale niskie dla innych, wskazuje to na aktywną partycję. Ten scenariusz wymaga dalszego zbadania.
Zmiana warstwy produktu jest obsługiwana przy użyciu witryny Azure Portal, interfejsu wiersza polecenia platformy Azure i wdrożenia szablonu usługi Azure Resource Manager (szablonu usługi ARM). Szablon ARM można wdrożyć lub edytować, zastępując poziom produktu jednym z następujących wartości:
Standard_E8s_v4Standard_E16s_v4Standard_E20s_v4Standard_E32s_v4Standard_DS13_v2Standard_DS14_v2Standard_D8s_v4Standard_D16s_v4Standard_D32s_v4Standard_L8s_v3Standard_L16s_v3Standard_L32s_v3Standard_L8as_v3Standard_L16as_v3Standard_L32as_v3
Obecnie nie obsługujemy przejścia między rodzinami produktów. Na przykład jeśli obecnie posiadasz element Standard_DS13_v2 i chcesz uaktualnić go do większego produktu, takiego jak Standard_DS14_v2, ta opcja nie jest dostępna. Otwórz bilet pomocy technicznej, aby poprosić o uaktualnienie do wyższego produktu.
Wydajność dysku
Usługa działa na dyskach zarządzanych platformy Azure P30, co pozwala na zwiększenie liczby IOPS. Dokładne monitorowanie jest wymagane w przypadku wąskich gardeł wydajności związanych z dyskiem. W takim przypadku ważne jest przejrzenie metryk IOPS.
Jeśli metryki pokazują jedną lub wszystkie następujące cechy, może być konieczne skalowanie w górę:
- Metryki są stale wyższe lub równe podstawowym IOPS. Pamiętaj, aby pomnożyć 5000 operacji we/wy na sekundę przez liczbę dysków na węzeł, aby uzyskać liczbę.
- Metryki są spójnie wyższe niż lub równe maksymalnej dozwolonej liczbie operacji we/wy na sekundę dla poziomu produktu w odniesieniu do operacji zapisu.
- Warstwa produktu obsługuje pamięć podręczną typu write-through, a ta liczba jest mniejsza niż IOPS pochodząca z dysków zarządzanych. Ta wartość stanowi górny limit IOPS odczytu.
Jeśli zauważysz podwyższoną wartość IOPS tylko dla kilku węzłów, może istnieć gorąca partycja i trzeba przejrzeć dane pod kątem potencjalnej nierównowagi.
Jeśli IOPS są niższe niż obsługiwane przez warstwę produktu, ale wyższe lub równe IOPS dysku, wykonaj następujące czynności:
- Dodaj więcej węzłów, aby skalować w górę centra danych.
Jeśli IOPS osiągną maksymalny limit obsługiwany przez poziom produktu, możesz:
- Przejdź na wyższą warstwę produktu, która obsługuje więcej operacji we/wy na sekundę.
- Dodaj więcej węzłów, aby skalować w górę centra danych.
Aby uzyskać więcej informacji, zobacz Wydajność maszyny wirtualnej i dysku.
Wydajność sieciowa
Zazwyczaj wydajność sieci jest wystarczająca. Jeśli 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, ta wydajność może stać się problemem. Może być konieczne oszacowanie wydajności sieci poziomu produktu. Na przykład Standard_DS14_v2 warstwa produktu obsługuje 12 000 Mb/s. Porównaj tę wartość z bajtami wejściowymi/wyjściowymi w ramach metryk.
Jeśli zostanie wyświetlony podwyższony poziom uprawnień sieci tylko dla kilku węzłów, może istnieć gorąca partycja. Przejrzyj rozkład danych i sposoby dostępu pod kątem potencjalnego skosu lub nierównomierności.
- Skalować pionowo do innego poziomu produktu, zwiększając przepustowość operacji we/wy sieciowej.
- Skalowanie w górę klastra w poziomie przez dodanie większej liczby węzłów.
Zbyt wielu połączonych klientów
Zaplanuj i przygotuj wdrożenia, aby obsługiwać maksymalną liczbę równoległych żądań potrzebnych do osiągnięcia docelowego czasu odpowiedzi aplikacji. W przypadku konkretnego 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 ta sytuacja nie przekracza dopuszczalnych limitów.
Miejsce na dysku
W większości przypadków jest wystarczająca ilość miejsca na dysku. Wdrożenia domyślne są zoptymalizowane pod kątem liczby operacji we/wy na sekundę, co prowadzi do niskiego wykorzystania dysku. Niemniej jednak zalecamy, aby od czasu do czasu przejrzeć metryki miejsca na dysku. System Cassandra gromadzi dużą liczbę dysków, a następnie konsoliduje je, gdy uruchomione zostanie kompaktowanie. Ważne jest, aby przejrzeć użycie dysku w dłuższych okresach, aby ustalić trendy, na przykład gdy kompaktowanie nie może odzyskać miejsca.
Uwaga
Aby zapewnić dostępne miejsce na kompaktowanie, zachowaj wykorzystanie dysku do około 50%.
Jeśli widzisz to zachowanie tylko dla kilku węzłów, możesz mieć do czynienia z gorącą partycją. Przejrzyj rozkład danych i sposoby dostępu pod kątem potencjalnego skosu lub nierównomierności.
- Dodaj więcej dysków, ale pamiętaj o limitach IOPS narzuconych przez warstwę produktu.
- Skalowanie klastra w poziomie.
Pamięć JVM
Nasza domyślna formuła przypisuje połowę pamięci maszyny wirtualnej do maszyny wirtualnej Java (JVM) z górnym limitem 31 GB. W większości przypadków takie podejście 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ć ograniczone pamięciowo.
W większości przypadków pamięć jest skutecznie odzyskiwana przez zbieracz śmieci języka Java. Jeśli procesor CPU jest często powyżej 80%, nie ma wystarczającej liczby cykli procesora CPU dla modułu odśmiecającego pamięci pozostawionego. Rozwiąż problemy z wydajnością procesora CPU przed sprawdzeniem problemów z pamięcią.
Jeśli wskaźnik myszy procesora CPU znajduje się poniżej 70%, a odzyskiwanie pamięci nie może odzyskać pamięci, może być konieczne użycie większej ilości pamięci JVM. Więcej pamięci JVM może być konieczne, jeśli korzystasz z warstwy produktu z ograniczoną ilością pamięci. W większości przypadków należy przejrzeć zapytania i ustawienia klienta oraz zmniejszyć liczbę elementów w fetch_size w połączeniu z wybranymi elementami w limit w zapytaniu języka Cassandra Query Language (CQL).
Jeśli potrzebujesz więcej pamięci, możesz:
- Skaluj w pionie do poziomu produktu, który ma więcej dostępnej pamięci.
Nagrobków
Uruchamiamy naprawy co siedem dni za pomocą systemu reaper, który usuwa wiersze, których czas życia (TTL) upłynął. Te wiersze są nazywane grobowcami. Niektóre obciążenia są usuwane częściej i w dziennikach bazy danych Cassandra wyświetlane są ostrzeżenia, takie jak Read 96 live rows and 5035 tombstone cells for query SELECT ...; token <token> (see tombstone_warn_threshold). Niektóre błędy wskazują, że nie można spełnić zapytania z powodu nadmiernych nagrobków.
Krótkoterminowe ograniczenie ryzyka, jeśli zapytania nie zostaną spełnione, to zwiększenie tombstone_failure_threshold wartości konfiguracji bazy danych Cassandra z domyślnej wartości 100 000 do wyższej wartości.
Zalecamy również przejrzenie wartości TTL w przestrzeni kluczy i ewentualne codzienne uruchamianie napraw w celu usunięcia większej liczby nagrobków. Jeśli wartości TTL są krótkie (na przykład krótsze niż dwa dni), a dane szybko przepływają i są usuwane, zalecamy przejrzenie strategii kompaktowania i preferowanie Leveled Compaction Strategy. W niektórych przypadkach takie akcje mogą wskazywać, że wymagany jest przegląd modelu danych.
Ostrzeżenia wsadowe
W usłudze CassandraLogs i potencjalnie powiązanych awariach może wystąpić następujące ostrzeżenie:
Batch for [<table>] is of size 6.740KiB, exceeding specified threshold of 5.000KiB by 1.740KiB.
Przejrzyj zapytania, aby pozostać poniżej zalecanego rozmiaru partii. W rzadkich przypadkach i jako chwilowe rozwiązanie zwiększ wartość batch_size_fail_threshold_in_kb w konfiguracji Cassandra z domyślnej 50 na wyższą wartość.
Ostrzeżenie o dużej partycji
W systemie CassandraLogs może wystąpić następujące ostrzeżenie:
Writing large partition <table> (105.426MiB) to sstable <file>
Ten komunikat wskazuje problem w modelu danych. Aby uzyskać więcej informacji, zobacz ten artykuł Stack Overflow. Ten problem może powodować poważne problemy z wydajnością i należy go rozwiązać.
Wyspecjalizowane optymalizacje
Kompresja
System Cassandra umożliwia wybór odpowiedniego algorytmu kompresji podczas tworzenia tabeli. 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 standardu Zstandard (Cassandra 4.0 i nowszych) pozwala zaoszczędzić około 12% miejsca z minimalnym obciążeniem procesora CPU.
Optymalizowanie przestrzeni sterty memtable
Wartością domyślną jest przeznaczenie jednej czwartej pamięci sterty JVM na memtable_heap_space w pliku cassandra.yaml. W przypadku aplikacji zorientowanych na zapis lub warstw produktów z małą ilością pamięci, ten problem może prowadzić do częstszego opróżniania i fragmentacji sstables, co wymaga większej liczby operacji kompaktowania. Zwiększenie do co najmniej 4048 może być dobre. Takie podejście wymaga starannego benchmarkingu, aby upewnić się, że nie ma to wpływu na inne operacje (na przykład odczyty).