Aanbevolen procedures voor optimale prestaties

Azure Managed Instance voor Apache Cassandra is een volledig beheerde service voor pure opensource Apache Cassandra-clusters. Met de service kunnen configuraties ook worden overschreven, afhankelijk van de specifieke behoeften van elke workload, waardoor de maximale flexibiliteit en controle waar nodig mogelijk zijn. In dit artikel vindt u tips voor het optimaliseren van de prestaties.

Optimale installatie en configuratie

Replicatiefactor, aantal schijven, aantal knooppunten en SKU's

Omdat ondersteuning voor Azure drie beschikbaarheidszones in de meeste regio's en Cassandra Managed Instance beschikbaarheidszones toe wijst aan racks, raden we u aan om een partitiesleutel met hoge kardinaliteit te kiezen om dynamische partities te voorkomen. Voor het beste niveau van betrouwbaarheid en fouttolerantie raden we u ten zeerste aan om een replicatiefactor van 3 te configureren. U wordt ook aangeraden een veelvoud van de replicatiefactor op te geven als het aantal knooppunten, bijvoorbeeld 3, 6, 9, enzovoort.

We gebruiken een RAID 0 over het aantal schijven dat u inricht. Om de optimale IOPS te verkrijgen moet u dus controleren op de maximale IOPS op de SKU die u hebt gekozen samen met de IOPS van een P30-schijf. De SKU ondersteunt bijvoorbeeld Standard_DS14_v2 51.200 IOPS zonder cache, terwijl één P30-schijf een basisprestatie van 5000 IOPS heeft. Vier schijven zouden dus leiden tot 20.000 IOPS, wat ruim onder de limieten van de machine ligt.

We raden u ten zeerste aan een uitgebreide benchmarking van uw workload uit te voeren op basis van de SKU en het aantal schijven. Benchmarking is vooral belangrijk in het geval van SKU's met slechts acht kernen. Uit ons onderzoek blijkt dat acht kern-CPU's alleen werken voor de minst veeleisende workloads en dat de meeste workloads minimaal 16 kernen nodig hebben om goed te presteren.

Analytische versus transactionele workloads

Transactionele workloads hebben doorgaans een datacenter nodig dat is geoptimaliseerd voor lage latentie, terwijl analytische workloads vaak complexere query's gebruiken, wat langer duurt om uit te voeren. In de meeste gevallen wilt u afzonderlijke datacenters:

• Eén geoptimaliseerd voor lage latentie
• Eén geoptimaliseerd voor analytische workloads

Optimaliseren voor analytische workloads

Klanten wordt aangeraden de volgende cassandra.yaml instellingen toe te passen voor analytische workloads (zie hier voor meer informatie over het toepassen).

Time-outs

Value	Standaard cassandra MI	Aanbeveling voor analytische workload
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

Caches

Value	Standaard cassandra MI	Aanbeveling voor analytische workload
file_cache_size_in_mb	2,048	6144

Meer aanbevelingen

Value	Standaard cassandra MI	Aanbeveling voor analytische workload
commitlog_total_space_in_mb	8,192	16,384
column_index_size_in_kb	64	16
compaction_throughput_mb_per_sec	128	256

Clientinstellingen

Het is raadzaam om time-outs van cassandra-clientstuurprogramma's te stimuleren in overeenstemming met de time-outs die op de server zijn toegepast.

Optimaliseren voor lage latentie

Onze standaardinstellingen zijn al geschikt voor workloads met lage latentie. Om de beste prestaties voor staartlatenties te garanderen, raden we u ten zeerste aan een clientstuurprogramma te gebruiken dat speculatieve uitvoering ondersteunt en uw client dienovereenkomstig configureert. Voor het Java V4-stuurprogramma vindt u een demo die laat zien hoe dit werkt en hoe u het beleid hier inschakelt.

Bewaking voor prestatiefleshalzen

CPU-prestaties

Net als elk databasesysteem werkt Cassandra het beste als het CPU-gebruik ongeveer 50% is en nooit hoger wordt dan 80%. U kunt metrische CPU-gegevens weergeven op het tabblad Metrische gegevens in Bewaking vanuit de portal:

Tip

Voor een realistische CPU-weergave voegt u een filter toe en splitst u de eigenschap op Usage kind=usage_idle. Als deze waarde lager is dan 20%, kunt u splitsing toepassen om gebruik te verkrijgen op basis van alle soorten gebruik.

Als de CPU voor de meeste knooppunten permanent hoger is dan 80%, wordt de database overbelast in meerdere time-outs van de client. In dit scenario raden we u aan de volgende acties uit te voeren:

• verticaal omhoog schalen naar een SKU met meer CPU-kernen (met name als de kernen slechts 8 of minder zijn).
• horizontaal schalen door meer knooppunten toe te voegen (zoals eerder vermeld, moet het aantal knooppunten meerdere van de replicatiefactor zijn).

Als de CPU slechts hoog is voor een paar knooppunten, maar voor de andere knooppunten laag, geeft dit een dynamische partitie aan en moet verder worden onderzocht.

Notitie

Het wijzigen van de SKU wordt ondersteund via Azure Portal, Azure CLI en ARM-sjabloonimplementatie. U kunt EEN ARM-sjabloon implementeren/bewerken en SKU vervangen door een van de volgende opties.

• 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

Houd er rekening mee dat we momenteel geen ondersteuning bieden voor de overgang tussen SKU-families. Als u momenteel bijvoorbeeld een Standard_DS13_v2 upgrade naar een grotere SKU hebt en geïnteresseerd bent in een upgrade naar een grotere SKU, Standard_DS14_v2is deze optie niet beschikbaar. U kunt echter een ondersteuningsticket openen om een upgrade naar de hogere SKU aan te vragen.

Schijfprestaties

De service wordt uitgevoerd op beheerde Azure P30-schijven, waardoor 'burst IOPS' mogelijk is. Zorgvuldige bewaking is vereist als het gaat om prestatieknelpunten met betrekking tot schijven. In dit geval is het belangrijk om de metrische IOPS-gegevens te controleren:

Als metrische gegevens een of alle volgende kenmerken bevatten, kan dit erop wijzen dat u omhoog moet schalen.

• Consistent hoger dan of gelijk aan de basis-IOPS (vergeet niet om 5000 IOPS te vermenigvuldigen met het aantal schijven per knooppunt om het getal op te halen).
• Consistent hoger dan of gelijk aan het maximum aantal IOPS dat is toegestaan voor de SKU voor schrijfbewerkingen.
• Uw SKU ondersteunt opslag in de cache (write-through-cache) en dit aantal is kleiner dan de IOPS van de beheerde schijven (dit is de bovengrens voor uw lees-IOPS).

Als u alleen de IOPS ziet verhoogd voor een paar knooppunten, hebt u mogelijk een dynamische partitie en moet u uw gegevens controleren op een mogelijke scheeftrekken.

Als uw IOPS lager zijn dan wat wordt ondersteund door de gekozen SKU, maar hoger of gelijk aan de IOPS van de schijf, kunt u de volgende acties uitvoeren:

• Voeg meer schijven toe om de prestaties te verbeteren. Voor het verhogen van schijven moet een ondersteuningsaanvraag worden gegenereerd.
• Schaal de datacenters omhoog door meer knooppunten toe te voegen.

Als uw IOPS maximaal krijgt wat uw SKU ondersteunt, kunt u het volgende doen:

• omhoog schalen naar een andere SKU die meer IOPS ondersteunt.
• Schaal de datacenters omhoog door meer knooppunten toe te voegen.

Raadpleeg de prestaties van virtuele machines en schijven voor meer informatie.

Netwerkprestaties

In de meeste gevallen zijn de netwerkprestaties voldoende. Als u echter regelmatig gegevens streamt (zoals frequent horizontaal omhoog/omlaag schalen) of als er enorme gegevensverplaatsingen voor inkomend/uitgaand verkeer zijn, kan dit een probleem worden. Mogelijk moet u de netwerkprestaties van uw SKU evalueren. De SKU ondersteunt bijvoorbeeld Standard_DS14_v2 12.000 Mb/s, vergelijk dit met de byte-in/out in de metrische gegevens:

Als u het netwerk alleen ziet verhoogd voor een paar knooppunten, hebt u mogelijk een dynamische partitie en moet u uw gegevensdistributie- en/of toegangspatronen controleren op een mogelijke scheefheid.

• Schaal verticaal omhoog naar een andere SKU die meer netwerk-I/O ondersteunt.
• Schaal het cluster horizontaal omhoog door meer knooppunten toe te voegen.

Te veel verbonden clients

Implementaties moeten worden gepland en ingericht ter ondersteuning van het maximum aantal parallelle aanvragen dat nodig is voor de gewenste latentie van een toepassing. Voor een bepaalde implementatie verhoogt het introduceren van meer belasting voor het systeem boven een minimumdrempel de totale latentie. Bewaak het aantal verbonden clients om ervoor te zorgen dat dit niet groter is dan de toegestane limieten.

Schijfruimte

In de meeste gevallen is er voldoende schijfruimte omdat standaardimplementaties zijn geoptimaliseerd voor IOPS, wat leidt tot een laag gebruik van de schijf. Niettemin adviseren we af en toe metrische gegevens over schijfruimte te controleren. Cassandra verzamelt veel schijven en vermindert deze wanneer compressie wordt geactiveerd. Daarom is het belangrijk om het schijfgebruik gedurende langere perioden te controleren om trends vast te stellen, zoals compressie die geen ruimte opnieuw kan coderen.

Notitie

Om ervoor te zorgen dat er ruimte beschikbaar is voor compressie, moet het schijfgebruik tot ongeveer 50% worden bewaard.

Als u dit gedrag alleen ziet voor een paar knooppunten, hebt u mogelijk een dynamische partitie en moet u de gegevensdistributie en/of toegangspatronen voor een mogelijke scheeftrekken controleren.

• voeg meer schijven toe, maar houd rekening met IOPS-limieten die zijn opgelegd door uw SKU
• het cluster horizontaal omhoog schalen

JVM-geheugen

Met onze standaardformule wordt de helft van het geheugen van de VIRTUELE machine toegewezen aan de JVM met een bovengrens van 31 GB, wat in de meeste gevallen een goede balans is tussen prestaties en geheugen. Sommige werkbelastingen, met name die regelmatig lees- of bereikscans tussen partities hebben, kunnen geheugenproblemen ondervinden.

In de meeste gevallen wordt geheugen effectief vrijgemaakt door de Java garbage collector, maar vooral als de CPU vaak hoger is dan 80% zijn er onvoldoende CPU-cycli voor de garbagecollector. Alle CPU-prestatieproblemen moeten dus worden opgelost voordat geheugenproblemen optreden.

Als de CPU lager is dan 70%, en de garbagecollection geen geheugen kan vrijmaken, hebt u mogelijk meer JVM-geheugen nodig. Dit is vooral het geval als u een SKU met beperkt geheugen gebruikt. In de meeste gevallen moet u uw query's en clientinstellingen controleren en samen met wat is gekozen in limit uw CQL-query verminderenfetch_size.

Als u inderdaad meer geheugen nodig hebt, kunt u het volgende doen:

• Dien een ticket in voor ons om de JVM-geheugeninstellingen voor u te verhogen
• Verticaal schalen naar een SKU met meer geheugen beschikbaar

Grafstenen

We voeren elke zeven dagen reparaties uit met reaper, die rijen verwijdert waarvan de TTL is verlopen (genaamd "tombstone"). Sommige workloads hebben vaker verwijderingen en zien waarschuwingen zoals Read 96 live rows and 5035 tombstone cells for query SELECT ...; token <token> (see tombstone_warn_threshold) in de Cassandra-logboeken of zelfs fouten die aangeven dat een query niet kan worden uitgevoerd vanwege overmatige tombstones.

Een kortetermijnbeperking als query's niet worden uitgevoerd, is het verhogen van de tombstone_failure_threshold cassandra-configuratie van de standaardwaarde 100.000 naar een hogere waarde.

Daarnaast raden we u aan om de TTL op de keyspace te controleren en mogelijk dagelijks reparaties uit te voeren om meer tombstones te wissen. Als de TTU's kort zijn, bijvoorbeeld minder dan twee dagen, en gegevens stromen en snel worden verwijderd, raden we u aan de compressiestrategie te bekijken en de voorkeur te geven Leveled Compaction Strategyaan . In sommige gevallen kunnen dergelijke acties een indicatie zijn dat een beoordeling van het gegevensmodel vereist is.

Batchwaarschuwingen

Deze waarschuwing kan optreden in de CassandraLogs en mogelijk gerelateerde fouten:

Batch for [<table>] is of size 6.740KiB, exceeding specified threshold of 5.000KiB by 1.740KiB.

In dit geval moet u uw query's controleren om onder de aanbevolen batchgrootte te blijven. In zeldzame gevallen en als een kortetermijnbeperking kunt u de Cassandra-configuratie verhogen batch_size_fail_threshold_in_kb van de standaardwaarde van 50 naar een hogere waarde.  

Waarschuwing voor grote partities

Deze waarschuwing kan optreden in de CassandraLogs:

Writing large partition <table> (105.426MiB) to sstable <file>

Dit duidt op een probleem in het gegevensmodel. Hier volgt een stack-overloopartikel dat uitgebreider ingaat. Dit kan ernstige prestatieproblemen veroorzaken en moet worden opgelost.

Gespecialiseerde optimalisaties

Compressie

Cassandra maakt het mogelijk om een geschikt compressiealgoritme te selecteren wanneer een tabel wordt gemaakt (zie Compressie) De standaardwaarde is LZ4, wat uitstekend is voor doorvoer en CPU, maar meer ruimte op schijf verbruikt. Met Zstd (Cassandra 4.0 en hoger) bespaart u ongeveer ongeveer 12% ruimte met minimale CPU-overhead.

Memtable heap ruimte optimaliseren

Onze standaardinstelling is om 1/4 van de JVM-heap te gebruiken voor memtable_heap_space in cassandra.yaml. Voor schrijfgeoriënteerde toepassingen en/of SKU's met een klein geheugen kan dit leiden tot frequente flushing en gefragmenteerde sstables, waardoor er meer compressie nodig is. In dergelijke gevallen kan het tot ten minste 4048 nuttig zijn, maar vereist zorgvuldige benchmarking om ervoor te zorgen dat andere bewerkingen (bijvoorbeeld leesbewerkingen) niet worden beïnvloed.

Volgende stappen

In dit artikel hebben we enkele aanbevolen procedures voor optimale prestaties beschreven. U kunt nu aan de slag met het cluster:

Een cluster maken met behulp van Azure Portal