Обработка записи блокировки кассандры, когда превышает memtable_cleanup_threshold - PullRequest
Новая
       12

Обработка записи блокировки кассандры, когда превышает memtable_cleanup_threshold

0 голосов
/ 13 февраля 2019

Я читал стратегии очистки cassandra и наткнулся на следующее утверждение: 

 If the data to be flushed exceeds the memtable_cleanup_threshold, Cassandra blocks writes until the next flush succeeds.

Теперь мой запрос, скажем, у нас есть безумные записи в cassandra около 10K записей в секунду, и приложение работает 24 *7.Какими должны быть настройки, которые мы должны установить в следующих параметрах, чтобы избежать блокировки. 

memtable_heap_space_in_mb 
memtable_offheap_space_in_mb 
memtable_cleanup_threshold

& Так как это данные временного ряда, нужно ли мне также вносить какие-либо изменения в стратегию сжатия.Если да, то что должно быть лучше для моего случая.

Мое искровое приложение, которое получает данные от kafka и постоянно вставляет их в Cassandra, зависает через определенное время, и я проанализировал в тот момент, есть много ожидающих выполнения задачв nodetool compactionstats. 

nodetool tablehistograms



 %       SSTables   WL             RL             P Size        Cell Count
                            (ms)           (ms)           (bytes)
50%     642.00    88.15           25109.16     310         24
75%     770.00    263.21         668489.53   535         50
95%     770.00    4055.27       668489.53   3311       310
98%     770.00    8409.01       668489.53   73457     6866
99%     770.00    12108.97     668489.53   219342   20501
Min      4.00        11.87           20924.30     150         9
Max     770.00    1996099.05 668489.53   4866323 454826


Keyspace : trackfleet_db
    Read Count: 7183347
    Read Latency: 15.153115504235004 ms
    Write Count: 2402229293
    Write Latency: 0.7495135263492935 ms
    Pending Flushes: 1
        Table: locationinfo
        SSTable count: 3307
        Space used (live): 62736956804
        Space used (total): 62736956804
        Space used by snapshots (total): 10469827269
        Off heap memory used (total): 56708763
        SSTable Compression Ratio: 0.38214618375483633
        Number of partitions (estimate): 493571
        Memtable cell count: 2089
        Memtable data size: 1168808
        Memtable off heap memory used: 0
        Memtable switch count: 88033
        Local read count: 765497
        Local read latency: 162.880 ms
        Local write count: 782044138
        Local write latency: 1.859 ms
        Pending flushes: 0
        Percent repaired: 0.0
        Bloom filter false positives: 368
        Bloom filter false ratio: 0.00000
        Bloom filter space used: 29158176
        Bloom filter off heap memory used: 29104216
        Index summary off heap memory used: 7883835
        Compression metadata off heap memory used: 19720712
        Compacted partition minimum bytes: 150
        Compacted partition maximum bytes: 4866323
        Compacted partition mean bytes: 7626
        Average live cells per slice (last five minutes): 3.5
        Maximum live cells per slice (last five minutes): 6
        Average tombstones per slice (last five minutes): 1.0
        Maximum tombstones per slice (last five minutes): 1
        Dropped Mutations: 359

После изменения стратегии сжатия: - 

Keyspace : trackfleet_db
    Read Count: 8568544
    Read Latency: 15.943608060365916 ms
    Write Count: 2568676920
    Write Latency: 0.8019530641630868 ms
    Pending Flushes: 1
        Table: locationinfo
        SSTable count: 5843
        SSTables in each level: [5842/4, 0, 0, 0, 0, 0, 0, 0, 0]
        Space used (live): 71317936302
        Space used (total): 71317936302
        Space used by snapshots (total): 10469827269
        Off heap memory used (total): 105205165
        SSTable Compression Ratio: 0.3889946058934169
        Number of partitions (estimate): 542002
        Memtable cell count: 235
        Memtable data size: 131501
        Memtable off heap memory used: 0
        Memtable switch count: 93947
        Local read count: 768148
        Local read latency: NaN ms
        Local write count: 839003671
        Local write latency: 1.127 ms
        Pending flushes: 1
        Percent repaired: 0.0
        Bloom filter false positives: 1345
        Bloom filter false ratio: 0.00000
        Bloom filter space used: 54904960
        Bloom filter off heap memory used: 55402400
        Index summary off heap memory used: 14884149
        Compression metadata off heap memory used: 34918616
        Compacted partition minimum bytes: 150
        Compacted partition maximum bytes: 4866323
        Compacted partition mean bytes: 4478
        Average live cells per slice (last five minutes): NaN
        Maximum live cells per slice (last five minutes): 0
        Average tombstones per slice (last five minutes): NaN
        Maximum tombstones per slice (last five minutes): 0
        Dropped Mutations: 660

Спасибо,

Ответы [ 2 ]

0 голосов
/ 13 февраля 2019

Я бы не трогал настройки памяти, если это не проблема.Они действительно будут блокироваться только в том случае, если ваша запись со скоростью, превышающей ваши возможности записи на диск, или ГХ испортили время.«10K записей в секунду и приложение работает 24 * 7» - на самом деле это не так уж и много, учитывая, что записи не очень велики по размеру и не будут переполнять записи (приличная система может выполнять постоянную загрузку 100k-200k / s).nodetool tablestats, tablehistograms, и схема может помочь определить, являются ли ваши записи слишком большими, слишком широкими разделами и дает лучший индикатор того, какой должна быть ваша стратегия сжатия (возможно, TWCS, но, возможно, LCS, если у вас есть какие-либо операции чтения и охват разделовдень или около того).

pending tasks in nodetool compactionstats не имеет ничего общего с настройками мемаблирования, так как это больше, чем то, что ваши уплотнения не поспевают.Это может быть что-то вроде скачков, когда выполняются массовые задания, сбрасываются небольшие разделы или восстанавливается sstables потока, но если он растет, а не падает, вам нужно настроить стратегию уплотнения.На самом деле многое зависит от модели данных и статистики (таблицы / гистограммы)

0 голосов
/ 13 февраля 2019

Вы можете обратиться по этой ссылке, чтобы настроить вышеуказанные параметры.http://abiasforaction.net/apache-cassandra-memtable-flush/

memtable_cleanup_threshold - процент от вашего общего доступного пространства памяти, которое запустит очистку памяти.memtable_cleanup_threshold по умолчанию равен 1 / (memtable_flush_writers + 1).По умолчанию это, по сути, 33% вашего memtable_heap_space_in_mb.Запланированная очистка приводит к очистке семейства таблиц / столбцов, которое занимает большую часть памяти.Это продолжается до тех пор, пока доступная память не упадет ниже порога очистки.

...