Question

我测试了具有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个写入（读取/写入发生在同一行）（不能使用行缓存）。在所有情况下，Read consistency = 2和Write Consistency = 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没有扩展太多，配置是否有任何问题？

Answer 1

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

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

我不知道它是否仅用于测试目的，但据我所知，Read before Write数据是Cassandra的反模式。

在卡桑德拉缩放

1 个答案: