Aanbevolen procedures voor optimale prestaties in Azure Managed Instance voor Apache Cassandra

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

Optimale installatie en configuratie

Replicatiefactor, aantal schijven, aantal knooppunten en productlagen

Azure ondersteunt drie beschikbaarheidszones in de meeste regio's. Azure Managed Instance voor Apache Cassandra wijst beschikbaarheidszones toe aan racks. We raden aan dat u een partitiesleutel met een hoge kardinaliteit kiest om hete 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. Gebruik bijvoorbeeld 3, 6, 9, enzovoort.

Azure gebruikt een RAID 0 over het aantal schijven dat u inricht. Als u de optimale invoer-/ouputbewerkingen per seconde (IOPS) wilt ophalen, controleert u op de maximale IOPS op de productlaag die u samen met de IOPS van een P30-schijf hebt gekozen. De productcategorie ondersteunt bijvoorbeeld 51.200 IOPS zonder cache Standard_DS14_v2. Eén P30-schijf heeft een basisprestatie van 5.000 IOPS. Vier schijven leiden tot 20.000 IOPS, die ruim onder de limieten van de machine ligt.

We raden u ten zeerste aan uw workload te benchmarken op basis van de productlaag en het aantal schijven. Benchmarking is vooral belangrijk voor productlagen met slechts acht kernen. Uit ons onderzoek blijkt dat acht core CPU's alleen werken voor de minst veeleisende workloads. De meeste workloads hebben minimaal 16 kernen nodig om goed te kunnen presteren.

Analytische versus transactionele werklasten

Transactionele workloads hebben doorgaans een datacenter nodig dat is geoptimaliseerd voor lage latentie. Analytische workloads maken vaak gebruik van complexere query's, die langer duren voordat ze worden uitgevoerd. In de meeste gevallen wilt u afzonderlijke datacenters met:

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

Optimaliseren van analytische werkbelastingen

U wordt aangeraden de volgende cassandra.yaml instellingen toe te passen voor analytische workloads. Zie Cassandra-configuratie bijwerken voor meer informatie over het toepassen van deze instellingen.

Time-outs

Caches

Meer aanbevelingen

Clientinstellingen

Het is raadzaam om de time-outs van Cassandra-clientstuurprogramma's te verhogen overeenkomstig 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 dat u uw client dienovereenkomstig configureert. Voor een Java V4-stuurprogramma illustreert een demo hoe dit proces werkt en hoe u het beleid in dit voorbeeld inschakelt.

Monitoren op prestatieknelpunten

CPU-prestaties

Net als elk databasesysteem werkt Cassandra het beste als het CPU-gebruik ongeveer 50% is en nooit hoger wordt dan 80%. Als u metrische CPU-gegevens wilt weergeven, opent u in Azure Portal onder de sectie Bewaking het tabblad Metrische gegevens .

Voor een realistische CPU-weergave voegt u een filter toe en gebruikt u Usage kind=usage_idle om de eigenschap te splitsen. Als deze waarde lager is dan 20%, past u splitsing toe om het gebruik voor alle gebruikstypen te verkrijgen.

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

• Schaal verticaal omhoog naar een productlaag met meer CPU-kernen, met name als de kernen slechts 8 of minder zijn.
• Schaal horizontaal door meer knooppunten toe te voegen. Zoals eerder vermeld, moet het aantal knooppunten een veelvoud van de replicatiefactor zijn.

Als de CPU hoog is voor slechts een paar knooppunten, maar laag voor de andere, duidt dit op een hete partitie. Dit scenario moet verder worden onderzocht.

Het wijzigen van de productlaag wordt ondersteund met behulp van de Azure-portal, de Azure CLI en Azure Resource Manager-sjabloonimplementatie (ARM-sjabloon). U kunt een ARM-sjabloon implementeren of bewerken en de productlaag vervangen door een van de volgende waarden:

• 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

Op dit moment bieden we geen ondersteuning voor de overgang tussen productfamilies. Als u momenteel bijvoorbeeld een Standard_DS13_v2 product bezit en een upgrade wilt uitvoeren naar een groter product, zoals Standard_DS14_v2, is deze optie niet beschikbaar. Open een ondersteuningsticket om een upgrade naar het hogere product aan te vragen.

Schijfprestaties

De service wordt uitgevoerd op door Azure P30 beheerde schijven, waardoor burst-IOPS mogelijk is. Er is zorgvuldige bewaking vereist bij schijfgerelateerde prestatieknelpunten. In dit geval is het belangrijk om de metrische IOPS-gegevens te controleren.

Als metrische gegevens een of meer van de volgende kenmerken bevatten, moet u mogelijk omhoog schalen:

• Uw metrische gegevens zijn 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.
• Uw metrische gegevens zijn consistent hoger dan of gelijk aan de maximaal toegestane IOPS voor de productlaag voor schrijfbewerkingen.
• Uw productlaag ondersteunt opslag in de cache (write-through-cache) en dit aantal is kleiner dan de IOPS van de beheerde schijven. Deze waarde is de bovengrens voor uw lees-IOPS.

Als u ziet dat de IOPS verhoogd is voor slechts een paar knooppunten, heeft u mogelijk een 'hot partition' en moet u uw gegevens controleren op mogelijke scheefgroei.

Als uw IOPS's lager zijn dan wat uw productlaag ondersteunt, maar hoger of gelijk aan de schijf-IOPS, voert u de volgende acties uit:

• Voeg meer knooppunten toe om de datacenters omhoog te schalen.

Als uw IOPS de bovengrens bereikt die uw productlaag ondersteunt, kunt u het volgende doen:

• Schaal omhoog naar een andere productlaag die ondersteuning biedt voor meer IOPS.
• Voeg meer knooppunten toe om de datacenters omhoog te schalen.

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

Netwerkprestaties

De netwerkprestaties zijn doorgaans voldoende. Als u gegevens regelmatig streamt, bijvoorbeeld door frequente horizontale opschaling/afschaling, of als er enorme databewegingen zijn, kunnen deze prestaties een probleem worden. Mogelijk moet u de netwerkprestaties van uw productlaag evalueren. De Standard_DS14_v2 productlaag ondersteunt bijvoorbeeld 12.000 Mb/s. Vergelijk deze waarde met de byte-in/out in de metrische gegevens.

Als u het netwerk verhoogd ziet voor slechts enkele knooppunten, hebt u mogelijk een hot partition. Controleer uw gegevensdistributie- en toegangspatronen voor een mogelijke scheefheid.

• Schaal verticaal omhoog naar een andere productlaag door ondersteuning te bieden voor meer netwerk-I/O.
• Schaal het cluster horizontaal omhoog door meer knooppunten toe te voegen.

Te veel verbonden clients

Plan en richt implementaties in ter ondersteuning van het maximum aantal parallelle aanvragen dat vereist is voor de gewenste latentie van een toepassing. Voor een specifieke implementatie verhoogt het introduceren van meer belasting voor het systeem boven een minimale drempelwaarde de totale latentie. Bewaak het aantal verbonden clients om ervoor te zorgen dat deze situatie niet groter is dan acceptabele limieten.

Schijfruimte

In de meeste gevallen is er voldoende schijfruimte. Standaardimplementaties zijn geoptimaliseerd voor IOPS, wat leidt tot een laag gebruik van de schijf. Niettemin raden we u aan af en toe metrische gegevens over schijfruimte te controleren. Cassandra verzamelt talloze schijven en vermindert deze wanneer compressie wordt geactiveerd. Het is belangrijk dat u het schijfgebruik gedurende langere perioden controleert om trends vast te stellen, bijvoorbeeld wanneer compressie geen ruimte opnieuw kan coderen.

Als u dit gedrag ziet bij slechts enkele knooppunten, hebt u mogelijk een hot partition. Controleer uw gegevensdistributie- en toegangspatronen voor een mogelijke scheefheid.

• Voeg meer schijven toe, maar houd rekening met de IOPS-limieten die zijn opgelegd door uw productlaag.
• Schaal het cluster horizontaal omhoog.

JVM-geheugen

Met onze standaardformule wordt de helft van het geheugen van de virtuele machine toegewezen aan de Java Virtual Machine (JVM) met een bovengrens van 31 GB. In de meeste gevallen is deze benadering een goede balans tussen prestaties en geheugen. Sommige workloads, met name workloads met frequente cross-partitie leesbewerkingen of bereikscans, kunnen geheugenintensief zijn.

In de meeste gevallen wordt geheugen effectief vrijgemaakt door de Java garbage collector. Als de CPU vaak hoger is dan 80%%, zijn er onvoldoende CPU-cycli over voor de garbage collector. Los problemen met cpu-prestaties op voordat u geheugenproblemen controleert.

Als de CPU onder de 70% beweegt en de garbagecollection geen geheugen kan vrijmaken, hebt u mogelijk meer JVM-geheugen nodig. Mogelijk is er meer JVM-geheugen nodig als u zich in een productlaag bevindt met beperkt geheugen. In de meeste gevallen moet u uw query's en clientinstellingen controleren en fetch_size samen met hetgeen gekozen in limit uw Cassandra Query Language (CQL)-query beperken.

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

• Schaal verticaal naar een productlaag met meer geheugen.

Grafstenen

We voeren om de zeven dagen reparaties uit met reaper, waardoor rijen worden verwijderd waarvan de time to live (TTL) is verlopen. Deze rijen worden tombstones genoemd. Sommige workloads voeren vaker verwijderingen uit en tonen waarschuwingen zoals Read 96 live rows and 5035 tombstone cells for query SELECT ...; token <token> (see tombstone_warn_threshold) in de Cassandra-logfiles. Sommige fouten geven aan dat een query niet kan worden uitgevoerd vanwege overmatige tombstones.

Een kortetermijnbeperking als er niet aan query's wordt voldaan, is het verhogen van de tombstone_failure_threshold waarde in de Cassandra-configuratie van de standaardwaarde 100.000 naar een hogere waarde.

We raden u ook aan om de TTL op de keyspace te bekijken en mogelijk dagelijks reparaties uit te voeren om meer tombstones te wissen. Als de TTL's kort zijn (bijvoorbeeld minder dan twee dagen) en gegevensstromen snel binnenkomen en worden verwijderd, raden we u aan de samenvoegstrategie te bekijken en Leveled Compaction Strategyde voorkeur te geven. In sommige gevallen kunnen dergelijke acties erop wijzen dat een beoordeling van het gegevensmodel vereist is.

Batchwaarschuwingen

Mogelijk ziet u de volgende waarschuwing in CassandraLogs en mogelijk gerelateerde fouten:

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

Controleer uw queries om binnen de aanbevolen batchgrootte te blijven. In zeldzame gevallen, en als een kortetermijnmaatregel, verhoog batch_size_fail_threshold_in_kb in de Cassandra-configuratie van de standaardwaarde van 50 naar een hogere waarde.

Waarschuwing voor grote partities

Mogelijk ziet u de volgende waarschuwing in CassandraLogs:

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

Dit bericht geeft een probleem aan in het gegevensmodel. Zie dit Stack Overflow-artikel voor meer informatie. Dit probleem kan ernstige prestatieproblemen veroorzaken en moet worden opgelost.

Gespecialiseerde optimalisaties

Compressie

Met Cassandra kunt u een geschikt compressie-algoritme selecteren wanneer een tabel wordt gemaakt. De standaardwaarde is LZ4, wat uitstekend is voor doorvoer en CPU, maar meer ruimte op schijf verbruikt. Met Zstandard (Cassandra 4.0 en hoger) bespaart u ongeveer 12% ruimte met minimale CPU-overhead.

Memtable heap-ruimte optimaliseren

De standaardinstelling is om een kwart van de JVM-heap te gebruiken voor memtable_heap_space in het cassandra.yaml bestand. Voor schrijfgeoriënteerde toepassingen of op productlagen met kleine hoeveelheden geheugen kan dit probleem leiden tot frequent leegmaken en gefragmenteerd sstables, wat meer compressie vereist. Verhogen tot ten minste 4.048 kan goed zijn. Deze benadering vereist zorgvuldige benchmarking om ervoor te zorgen dat andere bewerkingen (bijvoorbeeld leesbewerkingen) niet worden beïnvloed.

Volgende stap