5

当我运行“nodetool cfhistograms”时,我看到了一个表格数据。

Percentile  SSTables     Write Latency      Read Latency    Partition Size        Cell Count
                              (micros)          (micros)           (bytes)                  
50%             2.00              0.00           8239.00               924                20
75%             4.00              0.00           9887.00              1109                20
95%             4.00              0.00          51012.00              1916                24
98%             4.00              0.00          51012.00              2299                29
99%             4.00              0.00          51012.00              2759                35
Min             0.00              0.00            150.00                73                 2
Max             4.00              0.00          51012.00              3973                60

有人可以解释一下这些是如何计算的吗?我了解 %le 概念,但我想知道计算上述结果时考虑了多少读/写。

4

1 回答 1

4

它现在nodetool tablehistograms。每个表都有一个读取和写入的直方图,在本地读/写完成时更新。这不包括等待副本满足一致性级别等的网络时间nodetool proxyhistograms

有一点历史,它们随着时间的推移而变化,所以它取决于 cassandra 的版本来解释输出。几年前,我在这里的峰会上做了一次演讲,可以解释一些“为什么”。至于一段时间(仅 2.1),cfhistograms 是使用 Metrics 呈指数衰减的水库报告的,这是非常不准确的。在 2.1 之前,cfhistograms 的显示完全不同,但此时不值得一提。

目前它们由真实的直方图表示,而不是水库(EstimatedHistogram)。这些直方图有固定的桶,每个桶都比以前大 20%。由于它是固定的,因此存储的值只是一个 long[](atomiclongarray/longadder[] 具体取决于版本)。它会识别出哪个桶持有该值,因此在更糟糕的情况下,它会报告比实际情况差 20%。根据该直方图,百分位数是使用标准机制计算的。

保留了 2 个这些直方图。“所有时间”直方图和“最近”直方图。所有时间直方图是自 Cassandra 启动以来桶不断增加的地方。这可用于通过查找差异来准确判断自上次查看以来哪个存储桶中发生了多少事件。这个所有时间的直方图应该是被监控和警告的,因为它是准确的。“最近”直方图正向衰减存储桶的值。然后,较新的值比以前的值成倍增加,给出“大约最后 15 分钟”的视图,不是真正用于监控,而是用于临时查看它现在的样子。注意:这个最近的直方图直到3.0.9/3.8才存在,在 2.2 之间,然后 cfhistograms 报告了所有时间值。

“SSTables”列是读取时触及的 sstables 的数量。在CASSANDRA-13120中,“感动”的意思是改变了。以前,如果检查 sstable 上的布隆过滤器意味着可能的磁盘 IO,那么它就会被包括在内,但它只会通过令牌范围和时间戳过滤掉事物。现在,如果布隆过滤器从读取中排除了 sstable,则不计算在内。然后将其保存在上面提到的 2 个直方图中,用于延迟。

分区大小和单元计数是根据磁盘上的数据生成的。每个 sstable 都保留写入时计算的分区大小和单元格计数的直方图。当读取一个表的这个值时,它会合并来自所有 sstables 的统计信息,以生成用于百分位数计算的表宽直方图。

于 2018-05-31T21:52:41.740 回答