在 Cassandra 中进行缩放答案

【问题标题】：Scaling in Cassandra在 Cassandra 中进行缩放
【发布时间】：2018-05-29 19:20:25
【问题描述】：

我测试了具有 2,3 和 4 个节点的 Cassandra 集群的吞吐量性能。当我使用 3 个节点时（与 2 个相比）有显着改进，但是当我使用 4 个节点而不是 3 个节点时，改进并不那么显着。

以下是 4 个节点的规格：

N->No. of physical CPU cores, Ra->Total RAM, Rf->Free RAM

Node 1: N=16, Ra=189 GB, Rf=165 GB
Node 2: N=16, Ra=62 GB, Rf=44 GB
Node 3: N=12, Ra=24 GB, Rf=38 GB
Node 4: N=16, Ra=189 GB, Rf=24 GB

所有节点都在 RHEL 6.5 上

案例1（集群中2个节点，节点1和节点2）
Throughput: 12K ops/second
案例2（集群3个节点，节点1、节点2和节点3）
Throughput: 20K ops/second
案例 3（集群中的所有 4 个节点）
Throughput: 23K ops/second

1 次操作涉及 1 次读取 + 1 次写入（读取/写入发生在同一行）（不能使用行缓存）。在所有情况下，读取一致性 =2 和写入一致性 =1。读写都是异步的。客户端应用程序使用 Datastax 的 C++ 驱动程序并使用 10 个线程运行。

以下是键空间和表的详细信息：

CREATE KEYSPACE cass WITH replication = {'class': 'NetworkTopologyStrategy', 'dc1': '2'}  AND durable_writes = true;

CREATE TABLE cass.test_table (
    pk text PRIMARY KEY,
    data1_upd int,
    id1 int,
    portid blob,
    im text,
    isflag int,
    ms text,
    data2 int,
    rtdata blob,
    rtdynamic blob,
    rtloc blob,
    rttdd blob,
    rtaddress blob,
    status int,
    time bigint
) WITH bloom_filter_fp_chance = 0.001
    AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
    AND comment = ''
    AND compaction = {'class': 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
    AND compression = {'chunk_length_in_kb': '64', 'class': 'org.apache.cassandra.io.compress.LZ4Compressor'}
    AND crc_check_chance = 1.0
    AND dclocal_read_repair_chance = 0.1
    AND default_time_to_live = 0
    AND gc_grace_seconds = 864000
    AND max_index_interval = 2048
    AND memtable_flush_period_in_ms = 0
    AND min_index_interval = 128
    AND read_repair_chance = 0.0
    AND speculative_retry = '99PERCENTILE';

YAML 的一些参数如下（所有 4 个节点都使用类似的 YAML 文件）：

commitlog_segment_size_in_mb: 32
concurrent_reads: 64
concurrent_writes: 256
concurrent_counter_writes: 32
memtable_offheap_space_in_mb: 20480
memtable_allocation_type: offheap_objects
memtable_flush_writers: 1
concurrent_compactors: 2

jvm.options 中的一些参数如下（所有节点使用相同的值）：

### CMS Settings
-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:+CMSParallelRemarkEnabled
-XX:SurvivorRatio=4
-XX:MaxTenuringThreshold=6
-XX:CMSInitiatingOccupancyFraction=75
-XX:+UseCMSInitiatingOccupancyOnly
-XX:CMSWaitDuration=10000
-XX:+CMSParallelInitialMarkEnabled
-XX:+CMSEdenChunksRecordAlways
-XX:+CMSClassUnloadingEnabled

以下是一些客户端的连接特定参数：

cass_cluster_set_max_connections_per_host ( ms_cluster, 20 );
cass_cluster_set_queue_size_io ( ms_cluster, 102400*1024 );
cass_cluster_set_pending_requests_low_water_mark(ms_cluster, 50000);
cass_cluster_set_pending_requests_high_water_mark(ms_cluster, 100000);
cass_cluster_set_write_bytes_low_water_mark(ms_cluster, 100000 * 2024);
cass_cluster_set_write_bytes_high_water_mark(ms_cluster, 100000 * 2024);
cass_cluster_set_max_requests_per_flush(ms_cluster, 10000);
cass_cluster_set_request_timeout ( ms_cluster, 12000 );
cass_cluster_set_connect_timeout (ms_cluster, 60000);
cass_cluster_set_core_connections_per_host(ms_cluster,1);
cass_cluster_set_num_threads_io(ms_cluster,10);
cass_cluster_set_connection_heartbeat_interval(ms_cluster, 60);
cass_cluster_set_connection_idle_timeout(ms_cluster, 120);

当节点数量从 3 个增加到 4 个时，Cassandra 没有进行太多扩展的配置有什么问题吗？

【问题讨论】：

您确定您的应用程序能够使 Cassandra 饱和吗？看起来你的 JVM 设置也不是很理想——我建议不要调整除了 -Xmx/-Xms，并使用默认值——如果你使用的是 Java 8，那么默认值非常好
如果您在表结构中使用cassandra-stress，会显示什么结果？
我还没有在桌子上测试过 cassandra-stress。但是除了 JVM 设置之外，你觉得其他的一切都好吗？
另外，您所说的“应用程序能够使 Cassandra 饱和”到底是什么意思？
它发送了足够多的查询...我最好尝试使用cassandra-stress 测试集群，看看它的行为如何。 cassandra-stress 正在尝试增加并行请求的数量，直到达到最大吞吐量...

标签： cassandra cassandra-3.0

【解决方案1】：

在测试期间，您可以使用nodetool tpstats 检查ThreadPools。您将能够查看某些阶段是否有太多待处理（或被阻止）的任务。

如果 ThreadPools 没有问题，您是否可以使用 cassandra-stress 云启动基准测试，以查看限制是否来自您的客户端？

我不知道它是否仅用于测试目的，但据我所知，在写入数据之前读取是 Cassandra 的反模式。

【讨论】：