2

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

./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

我试图了解 nodetool cfstats、cfhistograms 与 OpsCenter 的结果。来自 Opscenter 的写入和读取请求延迟 (ms/op) 的表级指标是：
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的结果不匹配？是否像写的 opscenter y 轴值，读请求延迟必须在 micros/op 而不是 ms/op 中？

版本：
Cassandra 2.1.8.689
OpsCenter 5.2.2

如果我错了，请告诉我..!!
谢谢

4

1 回答 1

2

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

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

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

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

从特定表的 memtable 和 sstables 读取数据的响应时间的最小值、中值、最大值、第 90 个百分位和第 99 个百分位。从副本接收到协调器的请求并发送响应所经过的时间。

基于直方图的延迟

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

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

平均延迟将用自上次检查以来协调器写入的总时间除以自上次检查以来的协调器写入次数（请参阅https://github.com/apache/cassandra/blob/94ff639429a65acb5f122ed559e98dd60a40e42d/src/java/org/ apache/cassandra/metrics/LatencyMetrics.java#L125）。这可能与预期相差甚远，因为可能有很多 sub 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

于 2016-01-15T19:02:16.233 回答