私たちはこのカサンドラクラスターを持っており、現在のパフォーマンスが正常であるかどうか、そして改善するためにできることを知りたいと思います。カサンドラの書き込みパフォーマンス
クラスタは、同じデータセンターに配置された3つのノードで構成され、合計容量は465GB、ノードあたり2GBのヒープです。各ノードには8つのコアと8GBまたはRAMがあります。
- 鍵空間 （これは私たちにとって非常に重要である）org.apache.cassandra.locator.SimpleStrategy配置戦略と3の複製因子を使用して次のように異なるコンポーネントのバージョンは、ワークロードが記述されて
- ワークロードは、主に単一のテーブルへの書き込み操作で構成されます。テーブルスキーマは次のとおりです。
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;
cqlsh 5.0.1 | Cassandra 2.1.11.872 | DSE 4.7.4 | CQL spec 3.2.1 | Native protocol v3
をしています
書き込み操作はNodeJSベースのAPIサーバーから行われます。 Datastaxによって提供されるNodejsドライバが使用されます（バージョン2.1.1から3.2.0に最近更新されました）。書き込み要求を実行する担当者のコードは、主キーごとに書き込み操作をグループ化し、さらに要求ごとに500個のINSERTに制限します。書き込み操作はBATCHとして実行されます。明示的に設定される唯一のオプションはprepare:true, logged:falseです。
OpsCenterは、このセットアップを使用して、昨年の1秒未満の要求の履歴レベルを反映しています（各書き込み要求は、同じテーブルと同じパーティション向けの最大500操作のバッチでした）。書き込み要求レイテンシは、ほぼ1年間で要求の90％に対して1.6msでしたが、最近では要求の90％に対して2.6ms以上に増加しています。 Os Loadは2.0以下で、Disk Utilizationはほとんどの場合5％を下回り、7％のピークはほとんどありませんでした。平均ヒープ使用量は1.3GBで、今年のピーク時には1.6GBに達しています。
この設定の問題は、APIのパフォーマンスが1年中悪化していることです。現在、BATCH操作には300msから12秒を超える時間がかかります（操作のタイムアウトにつながります）。場合によっては、NodeJSドライバは、OpsCenterがすべてのノードが生き生きと健康であると報告しても、すべてのCassandraドライバを報告します。この問題を持つすべてのヘルプや提案が深く理解されるであろう
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
：
圧縮統計のようなものを見せている、常に0各ノードとnodetool tpstatsに示します。それを分析する必要がある他の情報を自由に要求してください。
敬具
はい、私たちは持っている年全体にわたって一定の要求レートこの設定で – yeiniel
任意のノードでrepair/scrub/rebuildを実行しようとしましたか？あなたがこれらのいずれかを最後にしたのはいつですか？ nodejsドライバを以前のバージョンに戻そうとしましたか？ – nevsv
問題の最初の対策として、先週クラスタ全体を修復します。スクラブと再構築とは何ですか？はい、私は戻って2.1.1に戻って、再び結果なしでnodejsドライバを元に戻します。 – yeiniel