卡桑德拉写入性能

Question

我们有这个Cassandra集群，想知道当前的性能是否正常，我们可以做些什么来改善它。

集群由位于同一数据中心的3个节点组成，每个节点的总容量为465GB，堆容量为2GB。每个节点有8个内核和8GB或RAM。不同组件的版本为cqlsh 5.0.1 | Cassandra 2.1.11.872 | DSE 4.7.4 | CQL规范3.2.1 |本机协议v3

工作量描述如下：

• 空格键使用org.apache.cassandra.locator。SimpleStrategy布局策略和复制因子为3（这对我们非常重要）
• 工作负载主要由写入单个表的操作组成。表模式如下：＜code＞CREATE table aiceweb。记录（process_id timeuuid，partition_key int，collected_at timestamp，received_at timestap，value text，PRIMARY key（（process _id，partition _key），collected_at，received_at）），并且read_repair_chance=0.0和dclocal_read_repiar_chance=0.1 AND gc_grace_seconds=864000 AND bloom_filter_fp_chance=0.01 AND缓存=｛“keys”：“ALL”，“rows_per_partition”：“NONE”｝AND注释=“”AND压缩=｛”class“：”org.apache.cassandra.db.compization.SizeTieredCompactionStrategy“｝和compression=｛“sstable_compression”：“org.apache.cassandra.io.compress.LZ4Compressor”｝AND default_time_to_live=0 AND suspective_retry=“99.0PERCENTILE”AND min_index_interval=128 AND max_index_ interval=2048

写操作来自基于NodeJS的API服务器。使用Datastax提供的Nodejs驱动程序（最近从2.1.1更新到3.2.0的版本）。负责执行写请求的代码将根据主键对写操作进行分组，此外，它还将每个请求的请求大小限制为500个INSERT。写操作作为BATCH执行。明确设置的唯一选项是准备：真，记录：假。

OpsCenter反映了去年使用此设置每秒不到一个请求的历史水平(每个写请求是一批多达500个操作，指向同一个表和同一个分区)。几乎全年，90%的请求的写请求延迟为1.6毫秒，但最近，90%的请求的写请求延迟增加到2.6毫秒以上。操作系统负载一直低于2.0，磁盘利用率大部分时间都低于5%，很少有峰值达到7%。全年的平均堆使用率为1.3GB，峰值为1.6GB，尽管当前峰值在上个月还在上升。

这种设置的问题是，API性能一整年都在下降。目前，批处理操作可能需要300毫秒到12秒以上(导致操作超时)。在某些情况下，NodeJS驱动程序会报告所有Cassandra驱动程序关闭，即使OpsCenter报告所有节点都正常运行。

压缩统计在每个节点上始终显示 0，节点工具 tpstats 显示如下内容：

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

对这个问题的任何帮助或建议都将深表感谢。如果你需要分析它，请随时索取任何其他信息。

此致敬意

Answer 1

我会尝试找到一个重现器，并在启用跟踪的情况下运行重现器——希望这将有助于理解问题所在(尤其是当您将其与延迟良好的跟踪进行比较时)。

有一个关于如何启用查询跟踪并通过nodejs驱动程序示例检索输出的示例retrieve-query-trace.js（可以在https://github.com/datastax/nodejs-driver找到）

Answer 2

您的请求数量保持不变，还是工作量在增加？

服务器似乎过载（可能是网络）。