Масштабирование в Кассандре - PullRequest
Новая
       6

Масштабирование в Кассандре

0 голосов
/ 29 мая 2018

Я проверил пропускную способность кластера Cassandra с 2,3 и 4 узлами.Было значительное улучшение, когда я использовал 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 консистенция = 2 и Write Consistency = 1.И чтение, и запись были асинхронными.Клиентское приложение использовало драйвер C ++ от Datastax и работало с 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?

1 Ответ

0 голосов
/ 29 мая 2018

Во время теста вы можете проверить ThreadPools , используя nodetool tpstats.Вы сможете увидеть, есть ли на некоторых этапах слишком много ожидающих (или заблокированных) задач.

Если проблем с ThreadPools нет, возможно, вы запускаете тестирование в облаке с помощью cassandra -ress чтобы узнать, исходит ли ограничение от вашего клиента?

Я не знаю, только ли оно для целей тестирования, но, насколько я знаю, «Чтение перед записью» - это антипаттерн с Кассандрой.

...