Osvědčené postupy pro optimální výkon
Azure Managed Instance for Apache Cassandra je plně spravovaná služba pro čistě opensourcové clustery Apache Cassandra. Služba také umožňuje přepsání konfigurací v závislosti na konkrétních potřebách jednotlivých úloh, což umožňuje maximální flexibilitu a kontrolu tam, kde je to potřeba. Tento článek obsahuje tipy, jak optimalizovat výkon.
Optimální nastavení a konfigurace
Faktor replikace, počet disků, počet uzlů a skladové položky
Vzhledem k tomu, že podpora Azure ve většině oblastí tři zóny dostupnosti a Spravovaná instance Cassandra mapuje zóny dostupnosti na racky, doporučujeme zvolit klíč oddílu s vysokou kardinalitou, aby nedocházelo k horkým oddílům. 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ů, například 3, 6, 9 atd.
Pro počet zřízených disků používáme RAID 0. Abyste získali optimální počet IOPS, musíte zkontrolovat maximální počet IOPS na skladové pořiďte společně s IOPS disku P30. Skladová položka Standard_DS14_v2 například podporuje 51 200 IOPS bez mezipaměti, zatímco jeden disk P30 má základní výkon 5 000 IOPS. Čtyři disky by tedy vedly k 20 000 IOPS, což je dobře pod limity počítače.
Důrazně doporučujeme provést rozsáhlé srovnávací testy vaší úlohy s skladovou jednotkou a počtem disků. Srovnávací testy jsou zvláště důležité v případě skladových položek s pouze osmi jádry. Náš výzkum ukazuje, že osm jader procesorů funguje jenom pro nejméně náročné úlohy a většina úloh potřebuje k výkonu minimálně 16 jader.
Analytické a transakční úlohy
Transakční úlohy obvykle potřebují datové centrum optimalizované pro nízkou latenci, zatímco analytické úlohy často používají složitější dotazy, které jejich spouštění trvá déle. Ve většině případů byste chtěli samostatná datová centra:
- Jedna optimalizovaná pro nízkou latenci
- Jedna optimalizovaná pro analytické úlohy
Optimalizace analytických úloh
Pro analytické úlohy doporučujeme zákazníkům použít následující cassandra.yaml nastavení (postup najdete tady ).
Č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 | 1,000 | 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í. Abychom zajistili nejlepší výkon pro koncové latence, důrazně doporučujeme použít klientský ovladač, který podporuje spekulativní spouštění a odpovídajícím způsobem konfiguruje klienta. Pro ovladač Java V4 najdete ukázku, která ilustruje, jak to funguje a jak povolit zásady.
Monitorování výkonových lahviček
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 %. Metriky procesoru můžete zobrazit na kartě Metriky na portálu:
Pokud je procesor trvale vyšší než 80 % pro většinu uzlů, databáze se přetíží v několika časových limitech klienta. V tomto scénáři doporučujeme provést následující akce:
- vertikálně navyšte kapacitu na skladovou položku s více jádry procesoru (zejména pokud jsou jádra pouze 8 nebo méně).
- horizontálně škálovat přidáním dalších uzlů (jak je uvedeno výše, počet uzlů by měl být násobek faktoru replikace).
Pokud je procesor jenom pro několik uzlů vysoký, ale pro ostatní, znamená to, že je horký oddíl a vyžaduje další šetření.
Poznámka:
Změna skladové položky se podporuje prostřednictvím webu Azure Portal, Azure CLI a nasazení šablon ARM. Šablonu ARM můžete nasadit nebo upravit a nahradit skladovou položku jedním z následujících způsobů.
- Standard_E8s_v4
- Standard_E16s_v4
- Standard_E20s_v4
- Standard_E32s_v4
- Standard_DS13_v2
- Standard_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
Upozorňujeme, že v současné době nepodporujeme přechod mezi rodinami skladových položek. Pokud například aktuálně máte a Standard_DS13_v2 zajímá vás upgrade na větší skladovou položku, například Standard_DS14_v2tato možnost není k dispozici. Můžete však otevřít lístek podpory a požádat o upgrade na vyšší skladovou položku.
Výkon disků
Služba běží na spravovaných discích Azure P30, což umožňuje "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, může to znamenat, že potřebujete vertikálně navýšit kapacitu.
- Konzistentně vyšší než nebo rovno základnímu IOPS (nezapomeňte číslo vynásobit 5 000 IOPS počtem disků na uzel).
- Konzistentně vyšší než nebo rovno maximálnímu počtu vstupně-výstupních operací za sekundu povolených pro skladovou položku pro zápisy.
- Vaše skladová položka podporuje úložiště uložené v mezipaměti (mezipaměť pro zápis) a toto číslo je menší než IOPS ze spravovaných disků (toto bude horní limit pro počet IOPS pro čtení).
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 je počet IOPS nižší, než je podporovaná vybranou skladovou jednotkou, ale vyšší nebo rovna IOPS disku, můžete provést následující akce:
- Přidejte další disky pro zvýšení výkonu. Zvýšení disků vyžaduje vyvolání případu podpory.
- Vertikálně navyšte kapacitu datových center přidáním dalších uzlů.
Pokud vaše IOPS maximum z toho, co vaše skladová položka podporuje, můžete:
- vertikálně navyšte kapacitu na jinou skladovou položku, která podporuje více IOPS.
- Vertikálně navyšte kapacitu datových center přidáním dalších uzlů.
Další informace najdete v tématu Výkon virtuálního počítače a disku.
Výkon sítě
Ve většině případů je dostatečný výkon sítě. Pokud ale často streamujete data (například časté horizontální vertikální navýšení nebo snížení kapacity) nebo dochází k velkému počtu příchozích/výchozích přesunů dat, může se to stát problémem. Možná budete muset vyhodnotit výkon sítě skladové položky. Skladová položka Standard_DS14_v2 například podporuje 12 000 Mb/s, porovnejte ji s bajtem in/out v metrikách:
Pokud se u několika uzlů zobrazí pouze zvýšená úroveň sítě, možná máte horký oddíl a potřebujete zkontrolovat rozdělení dat nebo vzory přístupu pro případnou nerovnoměrnou distribuci dat.
- Vertikálně navyšte kapacitu na jinou skladovou položku, která podporuje 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ů
Nasazení by se měla naplánovat a zřídit tak, aby podporovala maximální počet paralelních požadavků požadovaných pro požadovanou latenci aplikace. V případě daného nasazení představuje zavedení většího zatížení systému nad minimální prahovou hodnotu, která zvyšuje celkovou latenci. Monitorujte počet připojených klientů a ujistěte se, že to nepřekračuje přípustné limity.
Místo na disku
Ve většině případů je dostatek místa na disku, protože výchozí nasazení jsou optimalizovaná pro IOPS, což vede k nízkému využití disku. Přesto doporučujeme občas zkontrolovat metriky místa na disku. Cassandra shromažďuje velké množství disků a pak ho snižuje při aktivaci komprimace. Proto je důležité zkontrolovat využití disků v delších obdobích, aby se vytvořily trendy, jako je komprimace, která nemůže získat místo.
Poznámka:
Aby se zajistilo dostupné místo pro komprimace, mělo by se využití disku udržovat přibližně na 50 %.
Pokud se toto chování zobrazí jenom u několika uzlů, možná máte horký oddíl a potřebujete zkontrolovat rozdělení dat nebo vzory přístupu pro potenciální nerovnoměrnou distribuci dat.
- přidání dalších disků, ale mějte na paměti limity IOPS, které vaše skladová položka ukládá.
- horizontální navýšení kapacity clusteru
Paměť prostředí JVM
Náš výchozí vzorec přiřadí k prostředí JVM polovinu paměti virtuálního počítače s horním limitem 31 GB, což je ve většině případů dobrou rovnováhu mezi výkonem a pamětí. Některé úlohy, zejména úlohy, které mají časté kontroly čtení mezi oddíly nebo rozsahy, můžou být náročné na paměť.
Ve většině případů se paměť efektivně uvolní uvolňováním paměti Jazyka Java, ale zejména v případě, že procesor často překročí 80 % není dostatek cyklů procesoru pro uvolňování paměti. Všechny problémy s výkonem procesoru by se proto měly vyřešit před problémy s pamětí.
Pokud procesor najet pod 70 % a uvolňování paměti není možné uvolnit paměť, možná budete potřebovat více paměti JVM. To platí hlavně v případě, že používáte skladovou položku s omezenou pamětí. Ve většině případů je potřeba zkontrolovat dotazy a nastavení klienta a snížit fetch_size počet vybraných v limit dotazu CQL.
Pokud skutečně potřebujete více paměti, můžete:
- Vytvořte lístek pro nás, abychom zvýšili nastavení paměti prostředí JVM za vás.
- Vertikální škálování na skladovou položku, 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ž hodnota TTL vypršela (označuje se jako "náhrobek"). Některé úlohy mají častější odstranění a zobrazují se upozornění, jako jsou Read 96 live rows and 5035 tombstone cells for query SELECT ...; token <token> (see tombstone_warn_threshold) v protokolech Cassandra, nebo dokonce chyby, které značí, že dotaz nemohl být splněn kvůli nadměrným náhrobkům.
Krátkodobé zmírnění rizik v případě, že dotazy nedostanou splněné, je zvýšit tombstone_failure_threshold konfiguraci Cassandra z výchozích 100 000 na vyšší hodnotu.
Kromě toho doporučujeme zkontrolovat hodnotu TTL na prostoru klíčů a potenciálně spustit opravy denně, aby se vymazaly více náhrobků. Pokud jsou seznamy TTL krátké, například méně než dva dny, a toky dat se rychle odstraní, doporučujeme zkontrolovat strategii komprimace a upřednostňovat Leveled Compaction Strategy. V některýchpřípadechch
Dávková upozornění
K tomuto upozornění může dojít v CassandraLogs a potenciálně souvisejících selháních:
Batch for [<table>] is of size 6.740KiB, exceeding specified threshold of 5.000KiB by 1.740KiB.
V takovém případě byste měli zkontrolovat dotazy, abyste zůstali pod doporučenou velikostí dávky. Vevýjimečných batch_size_fail_threshold_in_kb
Upozornění velkého oddílu
V CassandraLogs můžete narazit na toto upozornění:
Writing large partition <table> (105.426MiB) to sstable <file>
To značí problém v datovém modelu. Tady je článek o přetečení zásobníku, který se podrobněji zabývá. To může způsobit závažné problémy s výkonem a je potřeba je vyřešit.
Specializované optimalizace
Komprese
Cassandra umožňuje výběr vhodného algoritmu komprese při vytvoření tabulky (viz Komprese) 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í Zstd (Cassandra 4.0 a novější) šetří přibližně 12 % místa s minimální režií na procesor.
Optimalizace prostoru memtable haldy
Naše výchozí hodnota je použít 1/4 haldy JVM pro memtable_heap_space v cassandra.yaml. U aplikací orientovaných na zápis nebo na skladové položky s malou pamětí to může vést k častému vyprázdnění a fragmentování sstables, což proto vyžaduje větší komprimace. V takovýchpřípadechch
Další kroky
V tomto článku jsme stanovili některé osvědčené postupy pro optimální výkon. Teď můžete začít pracovat s clusterem: