Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
Azure Managed Instance for Apache Cassandra je plně spravovaná služba pro čistě opensourcové clustery Apache Cassandra. Služba také umožňuje přepis konfigurací v závislosti na konkrétních potřebách jednotlivých pracovních úloh. Tato funkce umožňuje maximální flexibilitu a kontrolu podle potřeby. Tento článek obsahuje tipy, jak optimalizovat výkon.
Optimální nastavení a konfigurace
Faktor replikace, počet disků, počet uzlů a úrovně produktů
Azure podporuje tři zóny dostupnosti ve většině oblastí. Azure Managed Instance for Apache Cassandra mapuje zóny dostupnosti na racky. Doporučujeme zvolit klíč oddílu s vysokou kardinalitou, abyste se vyhnuli vytváření horkých oddílů. Pro zajištění nejvyšší úrovně spolehlivosti a odolnosti proti chybám důrazně doporučujeme nakonfigurovat faktor replikace 3. Doporučujeme také zadat násobek faktoru replikace jako počet uzlů. Použijte například 3, 6, 9 atd.
Azure používá RAID 0 na množství disků, které poskytnete. Pokud chcete získat optimální vstupně-výstupní operace za sekundu (IOPS), zkontrolujte maximální počet IOPS na úrovni produktu, kterou jste zvolili společně s IOPS disku P30.
Standard_DS14_v2 Například úroveň produktu podporuje 51 200 neukládaných do mezipaměti IOPS. Jeden disk P30 má základní výkon 5 000 IOPS. Čtyři disky vedou k 20 000 operacím vstupu/výstupu za sekundu, což je výrazně pod limity systému.
Důrazně doporučujeme provést rozsáhlé srovnávací testy úloh na úrovni produktu a počtu disků. Srovnávací testy jsou zvláště důležité pro úrovně produktů s pouze osmi jádry. Náš výzkum ukazuje, že procesory s osmi jádry pracují pouze pro nejméně náročné úlohy. Většina úloh potřebuje k správnému provedení minimálně 16 jader.
Analytické a transakční úlohy
Transakční úlohy obvykle potřebují datacentrum optimalizované pro nízkou latenci. Analytické úlohy často používají složitější dotazy, které poběží déle. Ve většině případů chcete samostatná datacentra:
- Jedna optimalizovaná pro nízkou latenci.
- Jedna optimalizovaná pro analytické úlohy.
Optimalizace pro analytické úlohy
Pro analytické úlohy doporučujeme použít následující cassandra.yaml nastavení. Další informace o tom, jak tato nastavení použít, najdete v tématu Aktualizace konfigurace Cassandra.
Časové limity
| Hodnota | Výchozí nastavení Cassandra MI | Doporučení pro analytické úlohy |
|---|---|---|
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 | 2 000 |
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 |
Mezipaměti
| Hodnota | Výchozí nastavení Cassandra MI | Doporučení pro analytické úlohy |
|---|---|---|
file_cache_size_in_mb |
2 048 | 6 144 |
Další doporučení
| Hodnota | Výchozí nastavení Cassandra MI | Doporučení pro analytické úlohy |
|---|---|---|
commitlog_total_space_in_mb |
8,192 | 16,384 |
column_index_size_in_kb |
64 | 16 |
compaction_throughput_mb_per_sec |
128 | 256 |
Nastavení klienta
Doporučujeme zvýšit časové limity klientských ovladačů Cassandra v souladu s časovými limity použitými na serveru.
Optimalizace pro nízkou latenci
Naše výchozí nastavení jsou už vhodná pro úlohy s nízkou latencí. Abyste zajistili nejlepší výkon pro koncové latence, důrazně doporučujeme použít klientský ovladač, který podporuje spekulativní spuštění a podle toho nakonfigurujete klienta. Pro ovladač Java V4 demo ilustruje, jak tento proces funguje a jak povolit politiku v této ukázce.
Monitorování kritických bodů výkonu
Výkon procesoru
Stejně jako každý databázový systém funguje Cassandra nejlépe, pokud využití procesoru je přibližně 50 % a nikdy se nedostane nad 80 %. Pokud chcete zobrazit metriky procesoru, otevřete na webu Azure Portal v části Monitorování kartu Metriky .
V zobrazení reálného procesoru přidejte filtr a použijte Usage kind=usage_idle k rozdělení vlastnosti. Pokud je tato hodnota nižší než 20%, proveďte rozdělení pro získání využití podle všech typů využití.
Pokud je procesor trvale vyšší než 80% pro většinu uzlů, databáze se přetíží, což se projevuje v několika časových limitech klienta. V tomto scénáři doporučujeme provést následující akce:
- Vertikální navýšení na úroveň produktové třídy s více jádry procesoru, zejména pokud je počet jader 8 nebo méně.
- Horizontální škálování přidáním dalších uzlů Jak už bylo zmíněno dříve, počet uzlů by měl být násobkem faktoru replikace.
Pokud je CPU vysoké jenom pro několik uzlů, ale nízké pro ostatní, ukazuje to na horký oddíl. Tento scénář vyžaduje další šetření.
Změna úrovně produktu se podporuje pomocí webu Azure Portal, Azure CLI a nasazení šablony Azure Resource Manageru (šablona ARM). Šablonu ARM můžete nasadit nebo upravit a nahradit produktovou úroveň jednou z následujících hodnot:
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
V současné době nepodporujeme přechod mezi rodinami produktů. Pokud například aktuálně máte Standard_DS13_v2 a chcete přejít na větší produkt, jako je Standard_DS14_v2, tato možnost není k dispozici. Otevřete podporní tiket a požádejte o upgrade k vyššímu produktu.
Výkon disků
Služba běží na spravovaných discích Azure P30, které umožňují nárazové IOPS. Pokud jde o kritické body výkonu související s disky, vyžaduje se pečlivé monitorování. V tomto případě je důležité zkontrolovat metriky IOPS.
Pokud metriky zobrazují jednu nebo všechny následující charakteristiky, budete možná muset vertikálně navýšit kapacitu:
- Vaše metriky jsou konzistentně vyšší nebo rovny základnímU IOPS. Nezapomeňte násobit 5 000 IOPS počtem disků na uzel, abyste získali číslo.
- Vaše metriky jsou konzistentně vyšší nebo rovny maximálnímu počtu vstupně-výstupních operací za sekundu povolenému pro úroveň produktu pro zápisy.
- Vaše úroveň produktu podporuje úložiště uložené v mezipaměti (mezipaměť pro zápis) a toto číslo je menší než počet IOPS ze spravovaných disků. Tato hodnota je horní limit počtu vstupně-výstupních operací čtení za sekundu.
Pokud se u několika uzlů zobrazí zvýšení počtu vstupně-výstupních operací za sekundu, je možné, že máte horký oddíl a budete muset zkontrolovat data a zjistit potenciální nerovnoměrnou distribuci.
Pokud jsou vaše IOPS nižší než to, co vaše úroveň produktu podporuje, ale vyšší nebo rovna IOPS disku, proveďte následující akce:
- Přidejte další uzly pro vertikální navýšení kapacity datacenter.
Pokud počet IOPS dosáhne horního limitu, který vaše úroveň produktu podporuje, můžete:
- Přejděte na jinou úroveň produktu, která nabízí vyšší počet IOPS.
- Přidejte další uzly pro vertikální navýšení kapacity datacenter.
Další informace najdete v tématu Výkon virtuálního počítače a disku.
Výkon sítě
Obvykle stačí výkon sítě. Pokud data streamujete často, například časté horizontální škálování nahoru/dolů, nebo dochází k velkým příchozím/výchozím pohybům dat, může se tento výkon stát problémem. Možná budete muset vyhodnotit výkon sítě vaší úrovně produktu.
Standard_DS14_v2 Například úroveň produktu podporuje 12 000 Mb/s. Porovnejte tuto hodnotu s bajty vstupu/výstupu v metrikách.
Pokud se zobrazí zvýšení úrovně sítě jenom u několika uzlů, možná máte horký oddíl. Prozkoumejte vzory distribuce dat a přístupu kvůli možné nerovnováze.
- Vertikálně navyšte kapacitu na jinou úroveň produktu tím, že podporujete více vstupně-výstupních operací sítě.
- Horizontálně vertikálně navyšte kapacitu clusteru přidáním dalších uzlů.
Příliš mnoho připojených klientů
Naplánujte a zřiďte nasazení, která podporují maximální počet paralelních požadavků, které jsou potřeba pro požadovanou latenci aplikace. V případě konkrétní implementace zavedení většího zatížení systému nad minimální prahovou hodnotu zvyšuje celkovou latenci. Monitorujte počet připojených klientů a zajistěte, aby tato situace nepřekračovala přípustné limity.
Místo na disku
Ve většině případů je dostatek místa na disku. Výchozí nasazení jsou optimalizovaná pro IOPS, což vede k nízkému využití disku. Přesto doporučujeme, abyste občas zkontrolovali metriky místa na disku. Cassandra shromažďuje množství disků a pak je snižuje při aktivaci komprimace. Je důležité sledovat využívání disku po delší dobu, aby se zjistily trendy, například pokud kompaktace nedokáže vrátit místo.
Poznámka:
Pokud chcete zajistit dostupné místo pro komprimace, udržujte využití disku přibližně na 50%.
Pokud se toto chování zobrazí jenom u několika uzlů, můžete mít horký oddíl. Prozkoumejte vzory distribuce dat a přístupu kvůli možné nerovnováze.
- Přidejte další disky, ale mějte na paměti limity IOPS stanovené vaší úrovní produktu.
- Horizontálně zvyšte škálovatelnost clustru.
Paměť prostředí JVM
Náš výchozí vzorec přiřadí polovinu paměti virtuálního počítače k virtuálnímu počítači Java Virtual Machine (JVM) s horním limitem 31 GB. Ve většině případů je tento přístup dobrou rovnováhou mezi výkonem a pamětí. Některé úlohy, zejména ty, které mají časté čtení napříč oddíly nebo rozsahové skeny, můžou být náročné na paměť.
Ve většině případů se paměť efektivně uvolní pomocí Java garbage kolektoru. Pokud je využití procesoru často nad 80%, nezbývá dostatek cyklů procesoru pro uvolňování paměti. Před kontrolou problémů s pamětí vyřešte problémy s výkonem procesoru.
Pokud se CPU pohybuje pod 70% a garbage collection nemůže získat paměť zpět, možná budete potřebovat více paměti JVM. Pokud jste na úrovni produktu s omezenou pamětí, může být potřeba více paměti JVM. Ve většině případů je potřeba zkontrolovat dotazy a nastavení klienta a snížit fetch_size počet vybraných položek v limit dotazu CQL (Cassandra Query Language).
Pokud potřebujete více paměti, můžete:
- Vertikálně škálujte na úroveň produktu, která má k dispozici více paměti.
Náhrobky
Opravy spouštíme každých sedm dní pomocí reaperu, který odebere řádky, jejichž čas do vypršení platnosti (TTL) vypršel. Tyto řádky se nazývají náhrobky. Některé úlohy se odstraňují častěji a zobrazují upozornění jako Read 96 live rows and 5035 tombstone cells for query SELECT ...; token <token> (see tombstone_warn_threshold) v protokolech Cassandra. Některé chyby značí, že dotaz nebylo možné splnit kvůli nadměrným náhrobkům.
Krátkodobým řešením v případě, že dotazy nejsou splněny, je zvýšit hodnotu parametru v konfiguraci Casandry z výchozí hodnoty 100 000 na vyšší.
Doporučujeme také zkontrolovat hodnotu TTL v prostoru s klíči a potenciálně spustit opravy každý den, aby se odstranilo více náhrobků. Pokud jsou časové limity krátké (například méně než dva dny) a toky dat se rychle ukládají a mažou, doporučujeme zkontrolovat strategii komprimace a upřednostňovat Leveled Compaction Strategy. V některých případech můžou takové akce znamenat, že se vyžaduje kontrola datového modelu.
Dávková upozornění
V CassandraLogs a potenciálně souvisejících selháních se může zobrazit následující upozornění:
Batch for [<table>] is of size 6.740KiB, exceeding specified threshold of 5.000KiB by 1.740KiB.
Zkontrolujte své dotazy, abyste zůstali pod doporučenou velikostí dávky. Ve výjimečných případech a jako krátkodobé zmírnění rizik zvyšte batch_size_fail_threshold_in_kbkonfiguraci Cassandra z výchozí hodnoty 50 na vyšší hodnotu.
Upozornění velkého oddílu
V CassandraLogs můžete narazit na následující upozornění:
Writing large partition <table> (105.426MiB) to sstable <file>
Tato zpráva označuje problém v datovém modelu. Další informace najdete v tomto článku o Stack Overflow. Tento problém může způsobit závažné problémy s výkonem a musí být vyřešen.
Specializované optimalizace
Komprese
Cassandra umožňuje výběr vhodného algoritmu komprese při vytvoření tabulky. Výchozí hodnota je LZ4, což je vynikající pro propustnost a procesor, ale spotřebovává více místa na disku. Použití Zstandard (Cassandra 4.0 a novější) šetří přibližně 12% prostoru s minimálním zatížením CPU.
Optimalizujte prostor paměti memtable
Výchozí nastavení je využít jednu čtvrtinu paměti haldy JVM pro memtable_heap_space ve cassandra.yaml souboru. U aplikací orientovaných na zápis nebo na úrovních produktů s malým množstvím paměti může tento problém vést k častému vyprázdnění a fragmentování sstables, které vyžadují větší komprimace. Zvýšení na alespoň 4 048 může být dobré. Tento přístup vyžaduje pečlivé srovnávací testy, aby se zajistilo, že ostatní operace (například čtení) nejsou ovlivněné.