Bewährte Methoden, um eine optimale Leistung in Azure Managed Instance for Apache Cassandra sicherzustellen

Azure Managed Instance for Apache Cassandra ist ein vollständig verwalteter Service für reine Open-Source Apache Cassandra-Cluster. Der Dienst ermöglicht auch das Überschreiben von Konfigurationen, je nach den spezifischen Anforderungen der einzelnen Arbeitsauslastungen. Dieses Feature ermöglicht maximale Flexibilität und Kontrolle bei Bedarf. Dieser Artikel enthält Tipps zum Optimieren der Leistung.

Optimale Einrichtung und Konfiguration

Replikationsfaktor, Anzahl von Datenträgern, Anzahl von Knoten und Produktebenen

Azure unterstützt drei Verfügbarkeitszonen in den meisten Regionen. Azure Managed Instance für Apache Cassandra ordnet Verfügbarkeitszonen Racks zu. Um heiße Partitionen zu vermeiden, wird empfohlen, einen Partitionsschlüssel mit hoher Kardinalität auszuwählen. Für das beste Maß an Zuverlässigkeit und Fehlertoleranz empfehlen wir dringend, einen Replikationsfaktor von 3 zu konfigurieren. Außerdem wird empfohlen, ein Vielfaches des Replikationsfaktors als Anzahl von Knoten anzugeben. Verwenden Sie z. B. 3, 6, 9 usw.

Azure verwendet einen RAID 0 über die Anzahl der Datenträger, die Sie bereitstellen. Um die optimalen Eingabe-/Outputvorgänge pro Sekunde (IOPS) zu erreichen, überprüfen Sie die maximalen IOPS der von Ihnen gewählten Produktstufe sowie die IOPS eines P30-Datenträgers. Zum Beispiel unterstützt die Produktstufe Standard_DS14_v2 51.200 nicht zwischengespeicherte IOPS. Ein einzelner P30-Datenträger verfügt über eine Basisleistung von 5.000 IOPS. Vier Datenträger führen zu 20.000 IOPS, was deutlich unter den Grenzen des Computers liegt.

Wir empfehlen dringend ein umfassendes Benchmarking Ihrer Workload gegenüber der Produktebene und der Anzahl von Datenträgern. Benchmarking ist besonders wichtig für Produktebenen mit nur acht Kernen. Unsere Forschung zeigt, dass acht kernige CPUs nur für die am wenigsten anspruchsvollen Workloads funktionieren. Die meisten Workloads benötigen mindestens 16 Kerne, um ordnungsgemäß ausgeführt zu werden.

Analytische vs. transaktionale Arbeitslasten

Transaktionsworkloads benötigen in der Regel ein Für niedrige Latenz optimiertes Rechenzentrum. Analytische Workloads verwenden häufig komplexere Abfragen, die die Ausführung länger dauern. In den meisten Fällen möchten Sie separate Rechenzentren mit:

• Eine Lösung, die für niedrige Latenz optimiert ist.
• Ein für analytische Workloads optimiertes System.

Optimieren für analytische Workloads

Es wird empfohlen, die folgenden cassandra.yaml Einstellungen für analytische Workloads anzuwenden. Weitere Informationen zum Anwenden dieser Einstellungen finden Sie unter Aktualisieren der Cassandra-Konfiguration.

Zeitlimits

Wert	Cassandra MI-Standardeinstellung	Empfehlung für 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

Wert	Cassandra MI-Standardeinstellung	Empfehlung für analytische Workload
file_cache_size_in_mb	2,048	6.144

Weitere Empfehlungen

Wert	Cassandra MI-Standardeinstellung	Empfehlung für 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

Clienteinstellungen

Es wird empfohlen, Cassandra-Clienttreibertimeouts entsprechend den auf dem Server angewendeten Timeouts zu erhöhen.

Optimieren für niedrige Latenz

Unsere Standardeinstellungen eignen sich bereits für Workloads mit geringer Latenz. Um die optimale Leistung für Taillatenzen sicherzustellen, empfehlen wir dringend, einen Client-Treiber zu verwenden, der spekulative Ausführung unterstützt, und dass Sie Ihren Client entsprechend konfigurieren. Für einen Java V4-Treiber veranschaulicht eine Demo, wie dieser Prozess funktioniert und wie die Richtlinie in diesem Beispiel aktiviert wird.

Überwachen von Leistungsengpässen

CPU-Leistung

Wie jedes Datenbanksystem funktioniert Cassandra am besten, wenn die CPU-Auslastung etwa 50 % beträgt und nie über 80 % liegt. Um CPU-Metriken anzuzeigen, öffnen Sie im Azure-Portal im Abschnitt "Überwachung " die Registerkarte "Metriken ".

Fügen Sie für eine realistische CPU-Ansicht einen Filter hinzu und verwenden Sie Usage kind=usage_idle um die Eigenschaft aufzuteilen. Wenn dieser Wert niedriger als 20%ist, wenden Sie die Aufteilung an, um alle Nutzungsarten zu berücksichtigen.

Wenn die CPU dauerhaft über 80% für die meisten Knoten liegt, wird die Datenbank überlastet, die in mehreren Clienttimeouts manifestiert wird. In diesem Szenario wird empfohlen, die folgenden Aktionen auszuführen:

• Vertikal auf eine Produktebene mit mehr CPU-Kernen skalieren, insbesondere, wenn die Kerne nur 8 oder weniger sind.
• Horizontal skalieren, indem weitere Knoten hinzugefügt werden. Wie bereits erwähnt, sollte die Anzahl der Knoten ein Vielfaches des Replikationsfaktors sein.

Wenn die CPU nur für wenige Knoten hoch ist, für die anderen jedoch niedrig ist, gibt sie eine heiße Partition an. Dieses Szenario erfordert eine weitere Untersuchung.

Das Ändern der Produktebene wird mithilfe des Azure-Portals, der Azure CLI- und der Azure Resource Manager-Vorlage (ARM-Vorlage) unterstützt. Sie können eine ARM-Vorlage bereitstellen oder bearbeiten und die Produktebene durch einen der folgenden Werte ersetzen:

• 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

Derzeit unterstützen wir den Übergang zwischen Produktfamilien nicht. Wenn Sie derzeit über ein Standard_DS13_v2 verfügen und zu einem größeren Produkt, wie z. B. Standard_DS14_v2, wechseln möchten, ist diese Option nicht verfügbar. Öffnen Sie ein Supportticket, um ein Upgrade auf das höhere Produkt anzufordern.

Datenträgerleistung

Der Dienst wird auf verwalteten Azure P30-Datenträgern ausgeführt, die Bursts an IOPS ermöglichen. Bei datenträgerbezogenen Leistungsengpässen ist eine sorgfältige Überwachung erforderlich. In diesem Fall ist es wichtig, die IOPS-Metriken zu überprüfen.

Wenn Metriken eines oder alle der folgenden Merkmale anzeigen, müssen Sie möglicherweise nach oben skalieren:

• Ihre Metriken sind konsistent höher als oder gleich dem Basis-IOPS. Denken Sie daran, 5.000 IOPS mit der Anzahl der Datenträger pro Knoten zu multiplizieren, um die Zahl abzurufen.
• Ihre Metriken sind konsistent höher als oder gleich dem maximalen IOPS, der für die Produktebene für Schreibvorgänge zulässig ist.
• Die Produktstufe unterstützt zwischengespeicherten Speicher (Write-through-Cache), und diese Zahl ist kleiner als die IOPS der verwalteten Datenträger. Dieser Wert ist die Obergrenze für Ihre Lese-IOPS.

Wenn die IOPS für nur wenige Knoten erhöht angezeigt wird, verfügen Sie möglicherweise über eine heiße Partition und müssen Ihre Daten auf eine mögliche Neigung überprüfen.

Wenn Ihre IOPS niedriger sind als die von Ihrer Produktebene unterstützten, aber höher oder gleich dem Datenträger-IOPS, führen Sie die folgenden Aktionen aus:

• Fügen Sie weitere Knoten hinzu, um die Rechenzentren zu skalieren.

Wenn Ihre IOPS den oberen Grenzwert erreichen, den Ihre Produktebene unterstützt, können Sie:

• Skalieren Sie auf eine andere Produktebene, die mehr IOPS unterstützt.
• Fügen Sie weitere Knoten hinzu, um die Rechenzentren zu skalieren.

Weitere Informationen finden Sie unter Virtuelle Computer und Datenträgerleistung.

Netzwerkleistung

In der Regel reicht die Netzwerkleistung aus. Wenn Sie Daten häufig streamen, etwa bei häufiger horizontaler Hochskalierung und Herunterskalierung oder bei großen Eingangs- und Ausgangsbewegungen, kann die Systemleistung zu einem Problem werden. Möglicherweise müssen Sie die Netzwerkleistung Ihrer Produktebene auswerten. Die Produktebene Standard_DS14_v2 unterstützt beispielsweise 12.000 MBit/s. Vergleichen Sie diesen Wert mit dem Byte-In/Out in den Metriken.

Wenn das Netzwerk nur für einige Knoten erhöht angezeigt wird, verfügen Sie möglicherweise über eine heiße Partition. Überprüfen Sie Ihre Datenverteilungs- und Zugriffsmuster auf eine mögliche Ungleichmäßigkeit.

• Skalieren Sie vertikal auf eine andere Produktebene, indem Sie mehr Netzwerk-E/A unterstützen.
• Skalieren Sie den Cluster horizontal hoch, indem Sie weitere Knoten hinzufügen.

Zu viele verbundene Clients

Planen und Bereitstellen von Bereitstellungen zur Unterstützung der maximalen Anzahl paralleler Anforderungen, die für die gewünschte Latenz einer Anwendung erforderlich sind. Bei einer bestimmten Bereitstellung erhöht die Einführung von mehr Last auf das System über einem Mindestschwellenwert die Gesamtlatenz. Überwachen Sie die Anzahl der verbundenen Clients, um sicherzustellen, dass diese Situation keine zulässigen Grenzwerte überschreitet.

Speicherplatz

In den meisten Fällen ist ausreichend Speicherplatz vorhanden. Standardbereitstellungen sind für IOPS optimiert, was zu einer geringen Auslastung des Datenträgers führt. Dennoch wird empfohlen, gelegentlich Datenträgerspeichermetriken zu überprüfen. Cassandra sammelt zahlreiche Datenträger und reduziert sie dann, wenn die Komprimierung ausgelöst wird. Es ist wichtig, die Datenträgernutzung über längere Zeiträume zu überprüfen, um Trends zu ermitteln, z. B. wenn die Komprimierung nicht in der Lage ist, Speicherplatz wieder herzustellen.

Hinweis

Um den verfügbaren Speicherplatz für die Komprimierung zu gewährleisten, halten Sie die Datenträgerauslastung auf ca. 50%.

Wenn dieses Verhalten nur für wenige Knoten angezeigt wird, verfügen Sie möglicherweise über eine heiße Partition. Überprüfen Sie Ihre Datenverteilungs- und Zugriffsmuster auf eine mögliche Ungleichmäßigkeit.

• Fügen Sie weitere Datenträger hinzu, achten Sie jedoch auf die IOPS-Grenzwerte, die von Ihrer Produktebene auferlegt werden.
• Horizontal skalieren Sie den Cluster nach oben.

JVM-Arbeitsspeicher

Unsere Standardformel weist dem Java Virtual Machine (JVM) mit einer Obergrenze von 31 GB halb den Arbeitsspeicher des virtuellen Computers zu. In den meisten Fällen ist dieser Ansatz ein gutes Gleichgewicht zwischen Leistung und Arbeitsspeicher. Bei einigen Workloads, insbesondere bei häufigen partitionsübergreifenden Lesevorgängen oder Bereichsscans, kann es zu Speicherproblemen kommen.

In den meisten Fällen wird der Speicher effektiv vom Java Garbage Collector freigegeben. Wenn die CPU häufig über 80%liegt, sind nicht genügend CPU-Zyklen für den Garbage Collector übrig. Beheben Sie CPU-Leistungsprobleme, bevor Sie Speicherprobleme überprüfen.

Wenn die CPU unter 70% bewegt wird und die Garbage Collection keinen Arbeitsspeicher zurückgibt, benötigen Sie möglicherweise mehr JVM-Speicher. Möglicherweise ist mehr JVM-Speicher erforderlich, wenn Sie sich auf einer Produktebene mit eingeschränktem Arbeitsspeicher befinden. In den meisten Fällen müssen Sie Ihre Abfragen und Clienteinstellungen überprüfen und fetch_size zusammen mit den ausgewählten Optionen in limit in Ihrer CQL-Abfrage (Cassandra Query Language) reduzieren.

Wenn Sie mehr Arbeitsspeicher benötigen, können Sie:

• Skalieren Sie vertikal auf eine Produktebene, die mehr Arbeitsspeicher zur Verfügung hat.

Grabsteine

Wir führen Reparaturen alle sieben Tage mit Reaper aus, wodurch Zeilen entfernt werden, deren Lebenszeit (TTL) abgelaufen ist. Diese Zeilen werden als Grabsteine bezeichnet. Einige Workloads löschen häufiger und zeigen Warnungen wie Read 96 live rows and 5035 tombstone cells for query SELECT ...; token <token> (see tombstone_warn_threshold) in den Cassandra-Protokollen an. Einige Fehler deuten darauf hin, dass eine Abfrage aufgrund übermäßiger Grabsteine nicht erfüllt werden konnte.

Eine kurzfristige Entschärfung, wenn Abfragen nicht erfüllt werden, besteht darin, den tombstone_failure_threshold Wert in der Cassandra-Konfiguration von der Standardeinstellung 100.000 auf einen höheren Wert zu erhöhen.

Außerdem empfehlen wir Ihnen, die TTL auf dem Keyspace zu überprüfen und möglicherweise täglich Reparaturen auszuführen, um weitere Grabsteine zu löschen. Wenn die TTLs kurz sind (z. B. weniger als zwei Tage), und Datenflüsse schnell gelöscht werden, empfehlen wir, die Komprimierungsstrategie zu überprüfen und zu bevorzugen Leveled Compaction Strategy. In einigen Fällen können solche Aktionen darauf hinweisen, dass eine Überprüfung des Datenmodells erforderlich ist.

Batchwarnungen

Möglicherweise tritt die folgende Warnung in CassandraLogs und möglicherweise zugehörigen Fehlern auf:

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

Überprüfen Sie Ihre Abfragen, um unter der empfohlenen Batchgröße zu bleiben. Erhöhen Sie in seltenen Fällen und als kurzfristige Gegenmaßnahme batch_size_fail_threshold_in_kb in der Cassandra-Konfiguration von der Standardeinstellung 50 auf einen höheren Wert.

Warnung für große Partitionen

Möglicherweise tritt in CassandraLogs die folgende Warnung auf:

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

Diese Meldung weist auf ein Problem im Datenmodell hin. Weitere Informationen finden Sie in diesem Stack Overflow-Artikel. Dieses Problem kann zu schwerwiegenden Leistungsproblemen führen und muss behoben werden.

Spezialisierte Optimierungen

Komprimierung

Cassandra ermöglicht die Auswahl eines geeigneten Komprimierungsalgorithmus, wenn eine Tabelle erstellt wird. Der Standardwert ist LZ4, der hervorragend für den Durchsatz und die CPU geeignet ist, aber mehr Speicherplatz auf dem Datenträger verbraucht. Die Verwendung von Zstandard (Cassandra 4.0 und up) spart etwa 12% Platz mit minimalem CPU-Aufwand.

Optimieren des memtable-Heapspeicherplatzes

Standardmäßig wird ein Viertel des JVM-Heaps für memtable_heap_space in der cassandra.yaml Datei verwendet. Bei schreiborientierten Anwendungen oder auf Produktebenen mit geringen Speichermengen kann dieses Problem zu häufigen Spülungen und Fragmentierungen sstablesführen, die eine größere Komprimierung erfordern. Eine Erhöhung auf mindestens 4.048 kann gut sein. Dieser Ansatz erfordert ein sorgfältiges Benchmarking, um sicherzustellen, dass andere Vorgänge (z. B. Lesevorgänge) nicht betroffen sind.

Nächster Schritt

Erstellen eines Clusters mit dem Azure-Portal