使用nodetool命令了解opscenter指标cfstats和cfhistograms结果

Question

我正在研究cassandra集群的基准测试，因此使用cassandra-stress工具。能够在其中一个表中插入1M记录，复制因子为2，CL为仲裁，线程速率为40，在2个节点上运行，并且运行压力为11.43.600.66。

  

./ cassandra-stress user profile = demo.yaml n = 1000000 ops（insert = 1，possiblequery0 = 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   

我试图了解nodetool cfstats的结果，与OpsCenter的结果一致。来自Opscenter的写入和读取RequestLatencies（ms / op）的表级度量标准是：

cfhistograms结果计算写入和读取延迟。延迟时间以微秒为单位
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的结果不匹配？它是否像opscenter y轴值write，readrequest Latency必须是micros / op而不是ms / op？

  

版本：
  卡桑德拉2.1.8.689
  OpsCenter 5.2.2

如果我错了，请告诉我。!!
感谢

Answer 1

这两种不同类型的指标在统计​​上有所不同。

首先，集群读/写延迟是协调器视图，包括可能的跨节点通信。如果将鼠标悬停在定义的度量标准上，则从opscenter开始：

  

客户端写入的平均响应时间（以毫秒为单位）。该   当节点收到客户端写请求时，时间段开始   当节点响应客户端时结束。取决于   一致性级别和复制因子，这可能包括网络   写入复制品的延迟。

在cfhistograms中，您正在查看该节点的本地延迟，这也是在CF：或TBL：metrics（取决于版本）下保存在OpsCenter中。有百分位图实际上会显示这个

  

响应时间的最小值，中位数，最大值，第90百分位数和第99百分位数   从memtable和sstables中读取特定表的数据。该   从副本收到来自的请求的经过时间   协调员并发送回复。

因此，从两个指标描述的角度来看，它的读/写水平不同。

此外 - 用于衡量它们的统计数据是不同的。

平均延迟将占用自上次检查以来协调器写入的总时间除以自上次检查后的协调器写入次数（请参阅https://github.com/apache/cassandra/blob/94ff639429a65acb5f122ed559e98dd60a40e42d/src/java/org/apache/cassandra/metrics/LatencyMetrics.java#L125）。这可能远远超出预期，因为可能存在大量子ms请求，而单个30秒的请求平均可达1ms。

“更好”的指标仍有一些统计损失，但在描述延迟的分布方面要好得多。这些（在cfhistograms的opscenter中的百分位数）通过表示每个表示时间范围的桶的延迟来更新。该直方图在请求期间更新。在OpsCenter中，它每分钟跟踪直方图的状态，并且根据差异可以确定每个时间段内发生的请求数。这还允许在群集视图中跨节点更加统计地准确地合并数据。如果一个节点有1000个请求而另一个节点有1个，则平均值将给出一半。通过添加每个节点桶的总数，它可以更好地表示实际的延迟分布。这里仍有损失，但相对较小。每个存储桶代表一个范围，我们不知道该存储区中的每个请求在该范围内发生了什么，但它足够小，足以“足够好”并且足够好地表示数量级。

Nodetool cfhistograms有几个版本要警惕。它使用https://en.wikipedia.org/wiki/Reservoir_sampling油藏采样算法（vitters r）而不是直方图，该直方图基于以下思想：正态分布可以用较小的数据样本表示。不幸的是，延迟是一种非常重的非正态分布，并且很容易降低数量级。 https://issues.apache.org/jira/browse/CASSANDRA-8662