Metodtips för optimala prestanda
Azure Managed Instance för Apache Cassandra är en fullständigt hanterad tjänst för rena Apache Cassandra-kluster med öppen källkod. Tjänsten tillåter också att konfigurationer åsidosätts, beroende på de specifika behoven för varje arbetsbelastning, vilket ger maximal flexibilitet och kontroll där det behövs. Den här artikeln innehåller tips om hur du optimerar prestanda.
Optimal konfiguration
Replikeringsfaktor, antal diskar, antal noder och SKU:er
Eftersom Azure har stöd för tre tillgänglighetszoner i de flesta regioner och Cassandra Managed Instance mappar tillgänglighetszoner till rack rekommenderar vi att du väljer en partitionsnyckel med hög kardinalitet för att undvika frekventa partitioner. För bästa möjliga tillförlitlighet och feltolerans rekommenderar vi starkt att du konfigurerar en replikeringsfaktor på 3. Vi rekommenderar också att du anger en multipel av replikeringsfaktorn som antalet noder, till exempel 3, 6, 9 osv.
Vi använder en RAID 0 över antalet diskar som du etablerar. Så för att få den optimala IOPS du behöver för att kontrollera om det maximala IOPS på SKU du har valt tillsammans med IOPS för en P30-disk. SKU:n stöder till exempel Standard_DS14_v2 51 200 ej anslutna IOPS, medan en enskild P30-disk har en basprestanda på 5 000 IOPS. Fyra diskar skulle alltså leda till 20 000 IOPS, vilket ligger långt under datorns gränser.
Vi rekommenderar starkt omfattande benchmarking av din arbetsbelastning mot SKU:n och antalet diskar. Benchmarking är särskilt viktigt när det gäller SKU:er med endast åtta kärnor. Vår forskning visar att åtta kärn-PROCESSORer endast fungerar för de minst krävande arbetsbelastningarna, och de flesta arbetsbelastningar behöver minst 16 kärnor för att fungera.
Analys jämfört med transaktionsarbetsbelastningar
Transaktionsarbetsbelastningar behöver vanligtvis ett datacenter som är optimerat för låg svarstid, medan analytiska arbetsbelastningar ofta använder mer komplexa frågor, vilket tar längre tid att köra. I de flesta fall vill du ha separata datacenter:
- En optimerad för låg svarstid
- En optimerad för analytiska arbetsbelastningar
Optimera för analytiska arbetsbelastningar
Vi rekommenderar att kunderna tillämpar följande cassandra.yaml inställningar för analytiska arbetsbelastningar (se här om hur du tillämpar).
Timeouter
| Värde | Cassandra MI-standard | Rekommendation för analytisk arbetsbelastning |
|---|---|---|
| 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 | 1 000 |
| roles_validity_in_ms | 2,000 | 120 000 |
| permissions_validity_in_ms | 2,000 | 120 000 |
Cachelagring
| Värde | Cassandra MI-standard | Rekommendation för analytisk arbetsbelastning |
|---|---|---|
| file_cache_size_in_mb | 2,048 | 6,144 |
Fler rekommendationer
| Värde | Cassandra MI-standard | Rekommendation för analytisk arbetsbelastning |
|---|---|---|
| commitlog_total_space_in_mb | 8,192 | 16,384 |
| column_index_size_in_kb | 64 | 16 |
| compaction_throughput_mb_per_sec | 128 | 256 |
Klientinställningar
Vi rekommenderar att du ökar tidsgränserna för Cassandra-klientdrivrutinen i enlighet med de tidsgränser som tillämpas på servern.
Optimera för låg svarstid
Våra standardinställningar är redan lämpliga för arbetsbelastningar med låg svarstid. För att säkerställa bästa prestanda för svarstider rekommenderar vi starkt att du använder en klientdrivrutin som stöder spekulativ körning och konfigurerar klienten i enlighet med detta. För Java V4-drivrutin kan du hitta en demo som illustrerar hur detta fungerar och hur du aktiverar principen här.
Övervakning av prestandaflaskhalsar
CPU-prestanda
Precis som alla databassystem fungerar Cassandra bäst om processoranvändningen är cirka 50 % och aldrig överstiger 80 %. Du kan visa CPU-mått på fliken Mått i Övervakning från portalen:
Om processorn är permanent över 80 % för de flesta noder blir databasen överlagrade manifest i flera klienttimeouter. I det här scenariot rekommenderar vi att du vidtar följande åtgärder:
- skala upp vertikalt till en SKU med fler CPU-kärnor (särskilt om kärnorna bara är 8 eller mindre).
- skala horisontellt genom att lägga till fler noder (som tidigare nämnts bör antalet noder vara flera av replikeringsfaktorn).
Om processorn bara är hög för några få noder, men låg för de andra, indikerar den en frekvent partition och behöver undersökas ytterligare.
Kommentar
Ändring av SKU stöds via Distribution av Azure-portalen, Azure CLI och ARM-mallar. Du kan distribuera/redigera ARM-mall och ersätta SKU med något av följande.
- 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
Observera att vi för närvarande inte stöder övergång mellan SKU-familjer. Om du till exempel för närvarande har en Standard_DS13_v2 och är intresserad av att uppgradera till en större SKU, till exempel Standard_DS14_v2, är det här alternativet inte tillgängligt. Du kan dock öppna ett supportärende för att begära en uppgradering till den högre SKU:n.
Diskprestanda
Tjänsten körs på Azure P30-hanterade diskar, vilket möjliggör "burst IOPS". Noggrann övervakning krävs när det gäller diskrelaterade prestandaflaskhalsar. I det här fallet är det viktigt att granska IOPS-måtten:
Om måtten visar en eller alla följande egenskaper kan det tyda på att du behöver skala upp.
- Konsekvent högre än eller lika med bas-IOPS (kom ihåg att multiplicera 5 000 IOPS med antalet diskar per nod för att hämta talet).
- Konsekvent högre än eller lika med den maximala IOPS som tillåts för SKU:n för skrivningar.
- Din SKU stöder cachelagrad lagring (write-through-cache) och det här talet är mindre än IOPS från de hanterade diskarna (det här är den övre gränsen för din läs-IOPS).
Om du bara ser IOPS förhöjd för några noder kanske du har en frekvent partition och behöver granska dina data för en potentiell skevhet.
Om din IOPS är lägre än vad som stöds av den valda SKU:n, men högre eller lika med disk-IOPS, kan du vidta följande åtgärder:
- Lägg till fler diskar för att öka prestandan. För att öka diskarna krävs ett supportärende.
- Skala upp datacenter genom att lägga till fler noder.
Om din IOPS maxar ut vad din SKU stöder kan du:
- skala upp till en annan SKU som stöder mer IOPS.
- Skala upp datacenter genom att lägga till fler noder.
Mer information finns i Virtuella datorer och diskprestanda.
Nätverksprestanda
I de flesta fall räcker det med nätverksprestanda. Men om du ofta strömmar data (till exempel frekvent horisontell uppskalning/nedskalning) eller om det finns enorma dataförflyttningar för inkommande/utgående data kan detta bli ett problem. Du kan behöva utvärdera nätverksprestandan för din SKU. SKU stöder till exempel Standard_DS14_v2 12 000 Mb/s, jämför detta med byte-in/ut i måtten:
Om nätverket bara är upphöjt för några få noder kan du ha en frekvent partition och behöver granska datadistributionen och/eller åtkomstmönstren för en potentiell skevhet.
- Skala upp vertikalt till en annan SKU som stöder mer nätverks-I/O.
- Skala upp klustret horisontellt genom att lägga till fler noder.
För många anslutna klienter
Distributioner bör planeras och etableras för att stödja det maximala antalet parallella begäranden som krävs för önskad svarstid för ett program. För en viss distribution ökar den totala svarstiden genom att införa mer belastning i systemet över ett minimitröskelvärde. Övervaka antalet anslutna klienter för att säkerställa att detta inte överskrider toleransgränser.
Diskutrymme
I de flesta fall finns det tillräckligt med diskutrymme eftersom standarddistributioner är optimerade för IOPS, vilket leder till låg användning av disken. Vi rekommenderar dock att du ibland granskar måtten för diskutrymme. Cassandra ackumulerar många diskar och minskar sedan när komprimering utlöses. Därför är det viktigt att granska diskanvändningen under längre perioder för att upprätta trender , till exempel komprimering som inte kan få tillbaka utrymme.
Kommentar
För att säkerställa tillgängligt utrymme för komprimering bör diskanvändningen hållas till cirka 50 %.
Om du bara ser det här beteendet för några få noder kanske du har en frekvent partition och behöver granska datadistributionen och/eller åtkomstmönstren för en potentiell skevhet.
- lägga till fler diskar men tänk på IOPS-begränsningar som införts av din SKU
- skala upp klustret vågrätt
JVM-minne
Vår standardformel tilldelar hälften av den virtuella datorns minne till JVM med en övre gräns på 31 GB , vilket i de flesta fall är en bra balans mellan prestanda och minne. Vissa arbetsbelastningar, särskilt de som har frekventa läsningar mellan partitioner eller intervallgenomsökningar, kan vara minnesutmaningar.
I de flesta fall frigörs minnet effektivt av Java-skräpinsamlaren, men särskilt om processorn ofta är över 80 % finns det inte tillräckligt med CPU-cykler för skräpinsamlaren kvar. Därför bör eventuella cpu-prestandaproblem åtgärdas före minnesproblem.
Om processorn hovrar under 70 % och skräpinsamlingen inte kan frigöra minne kan du behöva mer JVM-minne. Detta gäller särskilt om du använder en SKU med begränsat minne. I de flesta fall måste du granska dina frågor och klientinställningar och minska fetch_size tillsammans med vad som väljs i limit din CQL-fråga.
Om du verkligen behöver mer minne kan du:
- Skicka ett ärende till oss för att öka JVM-minnesinställningarna åt dig
- Skala lodrätt till en SKU som har mer minne tillgängligt
Gravstenar
Vi kör reparationer var sjunde dag med reaper, vilket tar bort rader vars TTL har upphört att gälla (kallas "tombstone"). Vissa arbetsbelastningar har mer frekventa borttagningar och ser varningar som Read 96 live rows and 5035 tombstone cells for query SELECT ...; token <token> (see tombstone_warn_threshold) i Cassandra-loggarna, eller till och med fel som indikerar att en fråga inte kunde uppfyllas på grund av för höga gravstenar.
En kortsiktig åtgärd om frågor inte uppfylls är att öka tombstone_failure_threshold i Cassandra-konfigurationen från standardvärdet 100 000 till ett högre värde.
Utöver detta rekommenderar vi att du granskar TTL på nyckelområdet och eventuellt kör reparationer dagligen för att rensa ut fler gravstenar. Om TTL:erna är korta, till exempel mindre än två dagar och data flödar in och tas bort snabbt, rekommenderar vi att du granskar komprimeringsstrategin Leveled Compaction Strategyoch föredrar . I vissa fall kan sådana åtgärder vara ett tecken på att en granskning av datamodellen krävs.
Batchvarningar
Du kan stöta på den här varningen i CassandraLogs och potentiellt relaterade fel:
Batch for [<table>] is of size 6.740KiB, exceeding specified threshold of 5.000KiB by 1.740KiB.
I det här fallet bör du granska dina frågor för att hålla dig under den rekommenderade batchstorleken. I sällsynta fall och som en kortsiktig åtgärd kan du öka batch_size_fail_threshold_in_kb i Cassandra-konfigurationen från standardvärdet 50 till ett högre värde.
Varning om stor partition
Du kan stöta på den här varningen i CassandraLogs:
Writing large partition <table> (105.426MiB) to sstable <file>
Detta indikerar ett problem i datamodellen. Här är en artikel om stackspill som går in mer detaljerat. Detta kan orsaka allvarliga prestandaproblem och måste åtgärdas.
Specialiserade optimeringar
Komprimering
Cassandra tillåter val av en lämplig komprimeringsalgoritm när en tabell skapas (se Komprimering) Standardvärdet är LZ4, vilket är utmärkt för dataflöde och CPU men förbrukar mer utrymme på disken. Om du använder Zstd (Cassandra 4.0 och uppåt) sparas cirka 12 % utrymme med minimal cpu-belastning.
Optimera memtable heap space
Standardvärdet är att använda 1/4 av JVM-heapen för memtable_heap_space i cassandra.yaml. För skrivorienterat program och/eller på SKU:er med litet minne kan detta leda till frekvent tömning och fragmenterade sstables vilket kräver mer komprimering. I sådana fall kan det vara fördelaktigt att öka till minst 4048, men kräver noggrann benchmarking för att se till att andra åtgärder (till exempel läsningar) inte påverkas.
Nästa steg
I den här artikeln har vi lagt fram några metodtips för optimala prestanda. Nu kan du börja arbeta med klustret: