Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
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 SKUs
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 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.
Azure verwendet einen RAID 0 über die Anzahl der von Ihnen bereitgestellten Datenträger. Um einen optimalen IOPS-Wert zu erhalten, ermitteln Sie den maximalen IOPS-Wert in der ausgewählten SKU zusammen mit dem IOPS-Wert eines P30-Datenträgers. 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. Vier Datenträger würden zu 20.000 IOPS führen, was deutlich unter den Grenzen 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 acht Kern-CPUs nur für die am wenigsten anspruchsvollen Workloads funktionieren. 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, die längere Ausführung erfordern. In den meisten Fällen möchten Sie separate Rechenzentren:
- Eines, das für geringe Wartezeit optimiert ist
- Eines, das für Analyseworkloads optimiert ist
Optimieren für analytische Workloads
Es wird empfohlen, dass Kunden die folgenden cassandra.yaml Einstellungen für analytische Workloads anwenden. Weitere Informationen zum Anwenden dieser Einstellungen finden Sie unter Aktualisieren der Cassandra-Konfiguration.
Auszeiten
| 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 |
|---|---|---|
| Datei-Cache-Größe_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 |
| Verdichtung_Durchsatz_MB_pro_Sekunde | 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 Java V4-Treiber finden Sie eine Demo, die zeigt, wie dies funktioniert und wie die Richtlinie in diesem Beispiel aktiviert wird.
Ü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 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 hochskalieren bis zu einer SKU mit mehr CPU-Kernen, insbesondere, wenn die Anzahl der Kerne 8 oder weniger beträgt.
- 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 einige Knoten hoch ist, für die anderen jedoch niedrig ist, gibt sie eine heiße Partition an, die weitere Untersuchungen erfordert.
Hinweis
Das Ändern der SKU wird mithilfe des Azure-Portals, der Azure CLI und der ARM-Vorlagenbereitstellung unterstützt. Sie können eine ARM-Vorlage bereitstellen oder bearbeiten und SKU 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 SKU-Familien nicht. Wenn Sie z. B. derzeit über eine Standard_DS13_v2 SKU verfügen und ein Upgrade auf eine größere SKU, wie z. B. Standard_DS14_v2, durchführen möchten, 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 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.
- Konstant 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.
- Konstant höher als oder gleich dem maximal zulässigen IOPS-Wert für die SKU für Schreibvorgänge.
- Das SKU 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 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 sind als das, was Ihre SKU unterstützt, und gleichzeitig höher oder gleich den Datenträger-IOPS sind, 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 , indem Sie weitere Knoten hinzufügen.
Wenn Ihre IOPS die von der SKU unterstützten Werte überschreiten, haben Sie folgende Möglichkeiten:
- Skalieren Sie bis zu einer anderen SKU, die mehr IOPS unterstützt.
- Skalieren Sie die Rechenzentren , indem Sie weitere Knoten hinzufügen.
Weitere Informationen finden Sie unter Virtuelle Computer und Datenträgerleistung.
Netzwerkleistung
In den meisten Fällen reicht die Netzwerkleistung aus. Wenn Sie jedoch häufig Daten streamen, wie z. B. häufige horizontale Skalierungs-/Skalierungsabskalierung, oder es große Ein-/Ausgang-Datenbewegungen gibt, kann diese Leistung zu einem Problem werden. Möglicherweise müssen Sie die Netzwerkleistung Ihrer SKU bewerten. Die Standard_DS14_v2 SKU unterstützt beispielsweise 12.000 Mb/s. Vergleichen Sie diesen Wert mit dem Byte-In/Out 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 Zugriffsmuster auf einen potenziellen Neigung 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
Sie sollten Bereitstellungen planen und bereitstellen, um die maximale Anzahl paralleler Anforderungen zu unterstützen, 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 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 Festplatten und reduziert diese 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. die Komprimierung, die keinen Speicherplatz wieder herstellen 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 einigen Knoten auftritt, deutet dies möglicherweise auf eine überlastete Partition hin und Sie sollten Ihre Datenverteilungs- und Zugriffsmuster auf ein mögliches Ungleichgewicht überprüfen.
- Fügen Sie weitere Datenträger hinzu, achten Sie jedoch auf IOPS-Grenzwerte, die von Ihrer SKU auferlegt werden.
- Horizontales Skalieren des Clusters
JVM-Arbeitsspeicher
Unsere Standardformel weist dem Jave 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. 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. Mehr JVM-Speicher kann erforderlich sein, wenn Sie sich auf einer SKU mit begrenztem Arbeitsspeicher befinden. 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.
Grabsteine
Wir führen Reparaturen alle sieben Tage mit dem Reaper aus, wodurch Zeilen entfernt werden, deren TTL abgelaufen ist, Tombstone genannt. 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 oder sogar Fehler an, die darauf hindeuten, dass eine Abfrage aufgrund übermäßiger Grabsteine nicht erfüllt werden konnte.
Eine kurzfristige Lösung, wenn Abfragen nicht erfüllt werden, besteht darin, den Wert in der tombstone_failure_thresholdCassandra-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
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 höheren Wert setzen.
Warnung für große Partitionen
Diese Warnung kann in den CassandraLogs auftreten:
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 Zstd (Cassandra 4.0 und höher) spart ca. 12 % Platz mit minimalem CPU-Aufwand.
Optimieren des memtable-Heapbereichs
Der Standardwert ist die Verwendung von 1/4 des JVM-Heaps für memtable_heap_space im 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 es gut sein, es auf mindestens 4048 zu erhöhen. Dieser Ansatz erfordert ein sorgfältiges Benchmarking, um sicherzustellen, dass andere Vorgänge, z. B. Lesevorgänge, nicht betroffen sind.