Cassandra Schreibleistung

Question

Wir haben diesen Cassandra-Cluster und möchten wissen, ob die aktuelle Leistung normal ist und was wir tun können, um sie zu verbessern.

Der Cluster besteht aus 3 Knoten, die sich im selben Datencenter befinden und eine Gesamtkapazität von 465 GB und 2 GB Heap pro Knoten aufweisen. Jeder Knoten hat 8 Kerne und 8 GB oder RAM. Version verschiedener Komponenten sind cqlsh 5.0.1 | Cassandra 2.1.11.872 | DSE 4.7.4 | CQL spec 3.2.1 | Native protocol v3

Die Arbeitsbelastung wird wie folgt beschrieben:

• Schlüsselraum verwenden org.apache.cassandra.locator.SimpleStrategy Platzierungsstrategie und Replikationsfaktor von 3 (das ist sehr wichtig für uns)
• Workload besteht hauptsächlich aus Schreibvorgängen in einer einzelnen Tabelle. Das Tabellenschema ist wie folgt: CREATE TABLE aiceweb.records ( process_id timeuuid, partition_key int, collected_at timestamp, received_at timestamp, value text, PRIMARY KEY ((process_id, partition_key), collected_at, received_at) ) WITH CLUSTERING ORDER BY (collected_at DESC, received_at ASC) AND read_repair_chance = 0.0 AND dclocal_read_repair_chance = 0.1 AND gc_grace_seconds = 864000 AND bloom_filter_fp_chance = 0.01 AND caching = { 'keys' : 'ALL', 'rows_per_partition' : 'NONE' } AND comment = '' AND compaction = { 'class' : 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy' } AND compression = { 'sstable_compression' : 'org.apache.cassandra.io.compress.LZ4Compressor' } AND default_time_to_live = 0 AND speculative_retry = '99.0PERCENTILE' AND min_index_interval = 128 AND max_index_interval = 2048;

Schreiboperationen kommen aus einem NodeJS basierten API-Server. Der von Datastax bereitgestellte Nodejs-Treiber wird verwendet (die Version wurde kürzlich von 2.1.1 auf 3.2.0 aktualisiert). Der Code, der für die Ausführung der Schreibanforderung verantwortlich ist, gruppiert Schreiboperationen pro Primärschlüssel und zusätzlich wird die Anforderungsgröße auf 500 INSERTs pro Anfrage begrenzt. Die Schreiboperation wird als BATCH ausgeführt. Die einzigen explizit gesetzten Optionen sind prepare:true, logged:false.

OpsCenter reflektieren eine historische Ebene von weniger als einer Anforderung pro Sekunde im letzten Jahr mit dieser Konfiguration (jede Schreibanforderung war ein BATCH von bis zu 500 Operationen, die an dieselbe Tabelle und dieselbe Partition gerichtet waren). Die Schreibanforderungslatenz betrug fast 90% der Anfragen für fast das gesamte Jahr bei 1,6 ms. In letzter Zeit ist sie jedoch auf mehr als 2,6 ms für die 90% der Anfragen gestiegen. Os Load lag unter 2,0 und die Festplattenauslastung lag die meiste Zeit unter 5% mit wenigen Spitzen bei 7%. Die durchschnittliche Heap-Nutzung betrug 1,3 GB das ganze Jahr über mit Spitzen bei 1,6 GB, obwohl dieser Höchstwert derzeit im letzten Monat steigt.

Das Problem bei dieser Konfiguration ist, dass die API-Leistung das ganze Jahr über beeinträchtigt wurde. Derzeit kann die BATCH-Operation von 300ms bis zu mehr als 12s dauern (was zu einem Operations-Timeout führt). In einigen Fällen meldet der NodeJS-Treiber alle Cassandra-Treiber auch dann, wenn OpsCenter alle Knoten als aktiv und gesund meldet.

Verdichtungs Statistik zeigt immer 0 auf jedem Knoten und nodetool tpstats zeigt so etwas wie:

Pool Name     Active Pending  Completed Blocked All time blocked 
CounterMutationStage    0   0   10554   0     0 
ReadStage       0   0   687567   0     0 
RequestResponseStage    0   0   767898   0     0 
MutationStage      0   0   393407   0     0 
ReadRepairStage     0   0   411   0     0 
GossipStage      0   0  1314414   0     0 
CacheCleanupExecutor    0   0    48   0     0 
MigrationStage     0   0    0   0     0 
ValidationExecutor    0   0   126   0     0 
Sampler       0   0    0   0     0 
MemtableReclaimMemory    0   0   497   0     0 
InternalResponseStage    0   0   126   0     0 
AntiEntropyStage     0   0   630   0     0 
MiscStage       0   0    0   0     0 
CommitLogArchiver     0   0    0   0     0 
MemtableFlushWriter    0   0   485   0     0 
PendingRangeCalculator   0   0    4   0     0 
MemtablePostFlush     0   0   7879   0     0 
CompactionExecutor    0   0   263599   0     0 
AntiEntropySessions    0   0    3   0     0 
HintedHandoff      0   0    8   0     0 

Message type   Dropped 
RANGE_SLICE     0 
READ_REPAIR     0 
PAGED_RANGE     0 
BINARY      0 
READ       0 
MUTATION      0 
_TRACE      0 
REQUEST_RESPONSE    0 
COUNTER_MUTATION    0 

Jede Hilfe oder Anregung mit diesem Problem wird sehr geschätzt werden. Fühlen Sie sich frei, irgendwelche anderen Informationen anzufordern, die Sie benötigen, um sie zu analysieren.

Mit freundlichen Grüßen

Answer 1

Sie sind mit der gleichen Anzahl von Anfragen zu bleiben, oder die Arbeitsbelastung wächst?

Sieht aus wie der Server überlastet ist (vielleicht Netzwerk).

Answer 2

Ich würde versuchen, einen Reproducer zu finden und den Reproduzierer mit Tracing aktiviert - hoffentlich hilft das zu verstehen, was das Problem ist (vor allem, wenn Sie es mit einer Spur vergleichen, in der die Latenz gut ist).

Es ist ein Beispiel dafür, wie Abfrage-Tracing aktivieren und die Ausgabe über NodeJS Treiber Beispiele abrufen-Abfrage-trace.js retrive (kann auf https://github.com/datastax/nodejs-driver zu finden)