Понимание метрик opscenter с результатами команд nodetool cfstats и cfhistograms

Я работаю над бенчмаркингом кластера cassandra и, следовательно, использую инструмент cassandra-stress. Возможность вставки 1 млн записей в одну из таблиц с коэффициентом репликации 2, CL в качестве кворума, скоростью потоков 40, на 2 узлах и рабочей нагрузкой от 11.43.600.66.

./cassandra-stress user profile= demo.yaml n=1000000 ops(insert=1,likelyquery0=2) cl= quorum -node 11.43.600.66,11.43.600.65 -rate threads=40

**demo.yaml script:**  
columnspec:  
  - name: user_name  
    size: gaussian(20..45)  
    population: gaussian(10000..50000)  
  - name: system_name  
    size: gaussian(20..45)  
    population: gaussian(50..60)  
  - name: time  
    size: uniform(15..25)  
    population: uniform(100000..1000000)  
  - name: request_uri  
    size: gaussian(50..80)  
    population: gaussian(100..150)  

insert:  
  partitions: fixed(1)            
  select:  fixed(1)/1000        
  batchtype: UNLOGGED

Я пытаюсь понять результаты cfstats, cfhistograms nodetool с результатами OpsCenter. Метрики уровня таблицы Write и Read RequestLatency (ms/op) от Opscenter:
WriteRequestLatency](http: //[WriterequestLatencygraphs ReadRequestLatency](http://[ReadRequestLatencygraphs
cfhistograms результаты для расчета записи и задержка чтения. Задержки указаны в микросекундах
cfhistogramsstats](http://[cfhistogramsstats
результаты cfstats в миллисекундах
cfstats](http://[результаты cfstats

a) As per the results of cfhistograms and cfstats  
Write Latency: 0.0117ms = 11.7 micros
Read Latency:  0.0943ms = 94.3 micros
This would approximately match the results at 50% as 
Write Latency: 10micros
Read Latency: 103micros

Вопрос 1: На основе какого процентиля cfstats и cfhistograms показывают результаты? Я бы всегда рассматривал 95%, но для 95% результаты cfstats не совпадают с cfhistograms здесь. Я считаю что-то не так?

b) From OpsCenter results:
Write Latency: 1.6ms/op = 1600 micros
Read Latency:  1.9ms/op = 1900 micros

Вопрос2: Почему несоответствие результатов cfhistograms и opscenter? Это похоже на то, что значения по оси y opscenter для записи и задержки запроса на чтение должны быть в микрос/операция вместо мс/операция?

Версии:
Cassandra 2.1.8.689
OpsCenter 5.2.2

Пожалуйста, дайте мне знать, если я ошибаюсь ..!!
Спасибо


cassandra nodetool cassandra-stress opscenter
person Arun    schedule 18.12.2015    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Это два разных вида метрик, которые отслеживаются статистически по-разному.

Начнем с того, что задержки чтения/записи кластера — это представление координатора, включая возможную связь между узлами. Из opscenter, если вы наведете курсор на метрику для определения:

Среднее время отклика (в миллисекундах) записи клиента. Период времени начинается, когда узел получает запрос клиента на запись, и заканчивается, когда узел отвечает клиенту. В зависимости от уровня согласованности и коэффициента репликации это может включать задержку в сети от записи в реплики.

Хотя в cfhistograms вы просматриваете локальные задержки для этого узла, они также хранятся в OpsCenter в метриках CF: или TBL: (в зависимости от версии). Существует график процентилей, который на самом деле покажет это

Минимальный, медианный, максимальный, 90-й и 99-й процентили времени отклика для чтения данных из memtable и sstables для конкретной таблицы. Время, прошедшее с момента, когда реплика получает запрос от координатора и отправляет ответ.

задержки на основе гистограммы

Итак, с точки зрения того, что описывают эти две метрики, разные уровни чтения/записи.

Кроме того, статистика, используемая для их измерения, отличается.

Средняя задержка будет равна общему количеству времени записи координатора с момента последней проверки, деленному на количество операций записи координатора с момента последней проверки (см. /java/org/apache/cassandra/metrics/LatencyMetrics.java#L125" rel="nofollow noreferrer">https://github.com/apache/cassandra/blob/94ff639429a65acb5f122ed559e98dd60a40e42d/src/java/org/apache/cassandra/ metrics/LatencyMetrics.java#L125). Это может быть далеко от того, что ожидается, поскольку может быть много запросов sub ms и один 30-секундный запрос, который в среднем будет равен 1 мс.

«Лучшие» показатели по-прежнему имеют некоторые статистические потери, но гораздо лучше описывают распределение задержек. Они (процентили в opscenter cfhistograms) обновляются, представляя задержки в сегментах, каждый из которых представляет временной диапазон. Эта гистограмма обновляется во время запроса. В OpsCenter он каждую минуту отслеживает состояние гистограммы и по разнице может определить, сколько запросов произошло в каждый период времени. Это также позволяет более статистически точно объединять данные между узлами в представлении кластера. Если у одного узла 1000 запросов, а у другого 1, усреднение даст половину пути. Добавляя итоговые значения сегментов каждого узла, можно лучше представить фактическое распределение задержки. Здесь все еще есть потери, но они сравнительно невелики. Каждое ведро представляет диапазон, и мы не знаем, где в этом диапазоне произошел каждый из запросов в этом ведре, но он достаточно мал, чтобы быть «достаточно хорошим» и достаточно хорошо представлять порядок величины.

У Nodetool cfhistograms было несколько версий, которых следует опасаться. Он использовал https://en.wikipedia.org/wiki/Reservoir_sampling алгоритм отбора проб резервуара ( vitters r) вместо гистограммы, основанной на идее, что нормальное распределение может быть представлено с помощью меньшей выборки данных. К сожалению, задержки представляют собой ненормальное распределение с очень тяжелыми хвостами, и оно может легко отличаться на порядки. https://issues.apache.org/jira/browse/CASSANDRA-8662

person Chris Lohfink    schedule 15.01.2016