Bewährte Methoden für eine optimale Leistung
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 Workloads, und bietet so ein Höchstmaß an Flexibilität und Kontrolle, wo dies erforderlich ist. Dieser Artikel enthält Tipps zum Optimieren der Leistung.
Optimale Einrichtung und Konfiguration
Replikationsfaktor, Anzahl von Datenträgern, Anzahl von Knoten und SKUs
Da Azure drei Verfügbarkeitszonen in den meisten Regionen unterstützt, und Cassandra Managed Instance Verfügbarkeitszonen Racks zuordnet, empfehlen wir, einen Partitionsschlüssel mit hoher Kardinalität zu wählen, um heiße Partitionen zu vermeiden. Für das beste Maß an Zuverlässigkeit und Fehlertoleranz empfehlen wir dringend die Konfiguration eines Replikationsfaktors von 3. Außerdem wird empfohlen, ein Vielfaches des Replikationsfaktors als Anzahl von Knoten anzugeben, z. B. 3, 6, 9 usw.
Wir verwenden einen RAID 0 über die Anzahl der Datenträger, die Sie bereitstellen. Um einen optimalen IOPS-Wert zu erhalten, müssen Sie also den maximalen IOPS-Wert in der ausgewählten SKU zusammen mit dem IOPS-Wert eines P30-Datenträgers ermitteln. Beispielsweise unterstützt die Standard_DS14_v2-SKU 51.200 nicht zwischengespeicherte IOPS, während ein einzelner P30-Datenträger eine Basisleistung von 5.000 IOPS aufweist. Daher würden vier Datenträger zu 20.000 IOPS führen, was deutlich unter den Grenzwerten des Computers liegt.
Es wird dringend empfohlen, ein umfangreiches Benchmarking Ihrer Workload mit der SKU und der Anzahl von Datenträgern durchzuführen. Benchmarking ist insbesondere bei SKUs mit nur acht Kernen wichtig. Unsere Forschung zeigt, dass CPUs mit acht Kernen nur für die am wenigsten anspruchsvollen Workloads funktionieren, und die meisten Workloads benötigen mindestens 16 Kerne, um leistungsfähig zu sein.
Analytische und Transaktionsworkloads
Transaktionsworkloads benötigen in der Regel ein Rechenzentrum, das für niedrige Latenz optimiert ist, während analytische Workloads häufig komplexere Abfragen verwenden, deren Ausführung länger dauert. In den meisten Fällen sollten Sie separate Rechenzentren verwenden:
- Eines, das für geringe Wartezeit optimiert ist
- Eines, das für Analyseworkloads optimiert ist
Optimieren für analytische Workloads
Wir empfehlen Kunden, die folgenden cassandra.yaml-Einstellungen für analytische Workloads anzuwenden (hier finden Sie Informationen zur Anwendung).
Timeouts
| Wert: | Cassandra-MI-Standard | 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-Standard | Empfehlung für analytische Workload |
|---|---|---|
| file_cache_size_in_mb | 2.048 | 6\.144 |
Weitere Empfehlungen
| Wert: | Cassandra-MI-Standard | 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
Wir empfehlen, Cassandra-Clienttreibertimeouts entsprechend den auf dem Server angewendeten Timeouts zu erhöhen.
Optimierung für niedrige Latenz
Unsere Standardeinstellungen sind für Workloads mit geringer Latenz bereits geeignet. Um eine optimale Leistung für die Taillatenz zu gewährleisten, empfehlen wir dringend die Verwendung eines Clienttreibers, der eine spekulative Ausführung unterstützt, und die entsprechende Konfiguration Ihres Clients. Für den Java V4-Treiber finden Sie hier eine Demo zur Veranschaulichung der Funktionsweise und zum Aktivieren der Richtlinie.
Überwachen auf Leistungsengpässe
CPU-Leistung
Wie jedes Datenbanksystem funktioniert Cassandra am besten, wenn die CPU-Auslastung etwa 50 % beträgt und nie über 80 % liegt. Sie können CPU-Metriken auf der Registerkarte „Metriken“ innerhalb der Überwachung über das Portal anzeigen:
Tipp
Fügen Sie für eine realistische CPU-Ansicht einen Filter hinzu, und teilen Sie die Eigenschaft nach Usage kind=usage_idle auf. Wenn dieser Wert niedriger als 20 % ist, können Sie die Trennung anwenden, um den Verbrauch nach allen Verbrauchsarten zu erhalten.
Wenn die CPU für die meisten Knoten dauerhaft über 80 % liegt, wird die Datenbank überlastet, was zu mehreren Clienttimeouts führt. In diesem Szenario wird empfohlen, die folgenden Aktionen auszuführen:
- Vertikal hochskalieren auf eine SKU mit mehr CPU-Kernen (insbesondere, wenn 8 oder weniger Kerne vorhanden 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-Auslastung nur für einige Knoten hoch ist, für die anderen jedoch niedrig, weist dies auf eine heiße Partition hin, für die weitere Untersuchungen erforderlich sind.
Hinweis
Das Ändern der SKU wird über das Azure-Portal, Azure CLI und ARM-Vorlagen unterstützt. Sie können eine ARM-Vorlage bereitstellen/bearbeiten und die SKU durch eine der folgenden 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
Bitte beachten Sie, dass derzeit kein Übergang zwischen SKU-Familien unterstützt wird. Wenn Sie z. B. über eine Standard_DS13_v2 verfügen und ein Upgrade auf eine größere SKU wie Standard_DS14_v2 beabsichtigen, ist diese Option nicht verfügbar. Sie können jedoch ein Supportticket öffnen, um ein Upgrade auf die höhere SKU anzufordern.
Datenträgerleistung
Der Dienst wird auf verwalteten Azure P30-Datenträgern ausgeführt, die „Burst 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 aufweisen, kann dies darauf hinweisen, dass Sie eine Skalierung ausführen müssen.
- Konstant höher als oder gleich dem IOPS-Basiswert (denken Sie daran, 5.000 IOPS mit der Anzahl der Datenträger pro Knoten zu multiplizieren, um den Wert zu erhalten).
- Konstant höher als oder gleich dem maximal zulässigen IOPS-Wert für die SKU für Schreibvorgänge.
- Ihre SKU unterstützt zwischengespeicherten Speicher (Write-Through-Cache), und diese Zahl ist kleiner als der IOPS-Wert der verwalteten Datenträger (dies ist die obere Grenze für Ihre Lese-IOPS).
Wenn IOPS nur für einige Knoten erhöht sind, verfügen Sie möglicherweise über eine heiße Partition und müssen Ihre Daten auf eine mögliche Schiefe überprüfen.
Wenn Ihre IOPS niedriger als der von der ausgewählten SKU unterstützte Wert sind, aber höher oder gleich dem Wert für Datenträger-IOPS, können Sie die folgenden Aktionen ausführen:
- Fügen Sie weitere Datenträger hinzu, um die Leistung zu steigern. Das Erhöhen der Datenträgerzahl erfordert, dass ein Supportfall ausgelöst wird.
- Skalieren Sie die Rechenzentren hoch, indem Sie weitere Knoten hinzufügen.
Wenn Ihre IOPS die von der SKU unterstützten Werte überschreiten, haben Sie folgende Möglichkeiten:
- Skalieren Sie auf eine andere SKU noch, die mehr IOPS unterstützt.
- Skalieren Sie die Rechenzentren hoch, indem Sie weitere Knoten hinzufügen.
Weitere Informationen finden Sie unter Leistung von VMs und Datenträgern.
Netzwerkleistung
In den meisten Fällen reicht die Netzwerkleistung aus. Wenn Sie jedoch häufig Daten streamen (z. B. häufiges horizontales Hoch-/Herunterskalieren) oder es große eingehende/ausgehende Datenverschiebungen gibt, kann dies zu einem Problem werden. Möglicherweise müssen Sie die Netzwerkleistung Ihrer SKU auswerten. Die Standard_DS14_v2-SKU unterstützt beispielsweise 12.000 Mb/s. Vergleichen Sie dies mit dem Byte-Eingang/Ausgang in den Metriken:
Wenn die Netzwerkwerte nur für wenige Knoten erhöht sind, verfügen Sie möglicherweise über eine heiße Partition und müssen Ihre Datenverteilung und/oder Zugriffsmuster auf einen potenziellen Schiefstand prüfen.
- Skalieren Sie vertikal auf eine andere SKU noch, die mehr Netzwerk-E/A-Vorgänge unterstützt.
- Skalieren Sie den Cluster horizontal hoch, indem Sie weitere Knoten hinzufügen.
Zu viele verbundene Clients
Bereitstellungen sollten so geplant und bereitgestellt werden, dass die maximale Anzahl paralleler Anforderungen unterstützt wird, die für die gewünschte Latenz einer Anwendung erforderlich sind. Für eine beliebige Bereitstellung erhöht die Einführung von mehr Last im System über einem Mindestschwellenwert die Gesamtlatenz. Überwachen Sie die Anzahl der verbundenen Clients, um sicherzustellen, dass hierdurch keine zulässigen Grenzwerte überschritten werden.
Speicherplatz
In den meisten Fällen ist ausreichend Speicherplatz vorhanden, da Standardbereitstellungen für IOPS optimiert sind, was zu einer geringen Auslastung des Datenträgers führt. Trotzdem empfehlen wir, gelegentlich die Speicherplatzmetriken für den Datenträger zu überprüfen. Cassandra akkumuliert viele Datenträger und reduziert sie dann, wenn die Komprimierung ausgelöst wird. Daher ist es wichtig, die Datenträgernutzung über längere Zeiträume zu überprüfen, um Trends zu ermitteln, z. B. dass die Komprimierung keinen Speicherplatz wiederherstellen kann.
Hinweis
Um verfügbaren Speicherplatz für die Komprimierung zu gewährleisten, sollte die Datenträgerauslastung auf etwa 50 % gehalten werden.
Wenn dieses Verhalten nur bei einer kleinen Anzahl von Knoten auftritt, verfügen Sie möglicherweise über eine heiße Partition und müssen Ihre Datenverteilung und/oder Zugriffsmuster auf eine potenzielle Schiefe prüfen.
- Fügen Sie weitere Datenträger hinzu, achten Sie jedoch auf die IOPS-Grenzwerte, die von Ihrer SKU vorgegeben werden.
- Skalieren Sie den Cluster horizontal hoch.
JVM-Arbeitsspeicher
Mit unserer Standardformel wird der JVM die Hälfte des VM-Arbeitsspeichers mit einer Obergrenze von 31 GB zugewiesen, was in den meisten Fällen ein gutes Gleichgewicht zwischen Leistung und Arbeitsspeicher darstellt. Einige Workloads, insbesondere solche, die häufig partitionsübergreifende Lesevorgänge oder Bereichsscans ausführen, können Herausforderungen für den Arbeitsspeicher darstellen.
In den meisten Fällen wird der Speicher effektiv vom Java Garbage Collector freigegeben, aber insbesondere, wenn die CPU häufig über 80 % liegt, sind nicht genügend CPU-Zyklen für den Garbage Collector übrig. Daher sollten alle CPU-Leistungsprobleme vor Speicherproblemen behoben werden.
Wenn die CPU unter 70 % liegt und die Garbage Collection nicht in der Lage ist, Arbeitsspeicher freizugeben, benötigen Sie möglicherweise mehr JVM-Speicher. Dies ist insbesondere der Fall, wenn Sie eine SKU mit eingeschränktem Arbeitsspeicher verwenden. In den meisten Fällen müssen Sie Ihre Abfragen und Clienteinstellungen überprüfen und fetch_size im Einklang mit den in limit ausgewählten Werten in Ihrer CQL-Abfrage reduzieren.
Wenn Sie wirklich mehr Arbeitsspeicher benötigen, haben Sie folgende Möglichkeiten:
- Erstellen Sie ein Ticket, damit wir die JVM-Speichereinstellungen für Sie erhöhen.
- Skalieren Sie vertikal auf eine SKU, die mehr Arbeitsspeicher zur Verfügung hat.
Tombstones
Wir führen alle sieben Tage Reparaturen mit Reaper durch, bei denen Zeilen entfernt werden, deren TTL abgelaufen ist (als „Tombstone“ bezeichnet). Einige Workloads haben häufigere Löschungen und sehen Warnungen wie Read 96 live rows and 5035 tombstone cells for query SELECT ...; token <token> (see tombstone_warn_threshold) in den Cassandra-Protokollen oder sogar Fehler, die darauf hindeuten, dass eine Abfrage aufgrund übermäßiger Tombstones nicht erfüllt werden konnte.
Eine kurzfristige Entschärfung, wenn Abfragen nicht erfüllt werden, besteht darin, tombstone_failure_threshold in der Cassandra-Konfiguration von der Standardeinstellung 100.000 auf einen größeren Wert zu erhöhen.
Darüber hinaus empfehlen wir, die TTL für den Keyspace zu überprüfen und ggf. täglich Reparaturen auszuführen, um weitere Tombstones zu löschen. Wenn die TTLs kurz sind, z. B. weniger als zwei Tage, und Daten schnell eingehen und gelöscht werden, empfehlen wir, die Komprimierungsstrategie zu überprüfen und Leveled Compaction Strategy zu bevorzugen. In einigen Fällen kann es sich dabei um einen Hinweis darauf handeln, dass eine Überprüfung des Datenmodells erforderlich ist.
Batchwarnungen
Diese Warnung kann in den CassandraLogs und potenziell damit verbundenen Fehlern auftreten:
Batch for [<table>] is of size 6.740KiB, exceeding specified threshold of 5.000KiB by 1.740KiB.
In diesem Fall sollten Sie Ihre Abfragen überprüfen, um unter der empfohlenen Batchgröße zu bleiben. In seltenen Fällen und als kurzfristige Entschärfung können Sie batch_size_fail_threshold_in_kb in der Cassandra-Konfiguration von der Standardeinstellung 50 auf einen größeren Wert erhöhen.
Warnung für große Partitionen
Diese Warnung kann in den CassandraLogs auftreten:
Writing large partition <table> (105.426MiB) to sstable <file>
Dies weist auf ein Problem im Datenmodell hin. In diesem Artikel zum Stapelüberlauf wird dies ausführlicher beschrieben. Dies 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 (siehe Komprimierung). Der Standardwert ist LZ4 und ist hervorragend für den Durchsatz und die CPU geeignet, verbraucht aber mehr Speicherplatz auf dem Datenträger. Die Verwendung von Zstd (Cassandra 4.0 und höher) spart ca. 12 % Platz mit minimalem CPU-Aufwand.
Optimieren des memtable-Heapbereichs
Unser Standard ist die Verwendung von 1/4 des JVM-Heaps für memtable_heap_space in „cassandra.yaml“. Bei schreiborientierten Anwendungen und/oder SKUs mit kleinem Arbeitsspeicher kann dies zu häufigen Leerungen und fragmentierten SSTables führen, wodurch eine größere Komprimierung erforderlich ist. In solchen Fällen kann die Erhöhung auf mindestens 4048 von Vorteil sein, erfordert jedoch ein sorgfältiges Benchmarking, um sicherzustellen, dass andere Vorgänge (zum Beispiel Lesevorgänge) nicht beeinträchtigt werden.
Nächste Schritte
In diesem Artikel haben wir einige bewährte Methoden für eine optimale Leistung erläutert. Sie können jetzt beginnen, mit dem Cluster zu arbeiten.