当我运行'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概念，但我想知道有多少读/写被认为是计算上述结果。
答案 0 :(得分：1)
现在nodetool tablehistograms。每个表都有一个读写直方图，在完成本地读/写后会更新。这不包括等待副本满足一致性级别等的网络时间，即nodetool proxyhistograms。
Theres有点历史，随着时间的推移它们会发生变化，所以它取决于cassandra的版本来解释输出。几年前我在峰会上发表了一篇演讲here，可以解释一些＆＃34;为什么＆＃34;。至于一段时间（仅2.1），使用Metrics指数衰减的储层报告了cfhistograms，这是非常不准确的。在2.1之前，cfhistograms显示完全不同，但此时不值得一提。
目前，它们由真实的直方图表示，而不是水库（EstimatedHistogram）。这些直方图有固定的桶，每个桶比以前大20％。由于它固定了存储的值只是一个long []（atomiclongarray / longadder []，具体取决于版本）。它确定哪个桶具有该值，因此在更糟糕的情况下，它报告的实际情况比实际情况差20％。从该直方图中，使用标准机制计算百分位数。
保留了这些直方图中的2个。一直＆＃34;所有时间＆＃34;直方图和＆＃34;最近＆＃34;直方图。从Cassandra时间开始，所有时间直方图都是桶不断增加的地方。这可以用于准确地告知自上次查找时在哪个桶中发生了多少事件，找出它们之间的差异。这个所有时间直方图应该是被监控和警告的准确的。 ＆＃34;最近＆＃34;直方图forward decays桶的值。然后，更近期的值比以前的值成倍地计算，给出了大约15min-ish＆＃34;查看，不是真正用于监控，而是用于查看现在的内容。注意：这个最近的直方图直到3.0.9/3.8才存在，在2.2之间，然后cfhistograms报告所有时间值。
＆＃34; SSTables＆＃34; column是读取时触及的sstables的数量。什么＆＃34;感动＆＃34;意味着在CASSANDRA-13120中更改了。以前，如果在sstable上检查bloomfilter意味着可能包含磁盘IO，那么它只会按令牌范围和时间戳过滤掉事物。现在，如果bloomfilter从读取中排除sstable，则不计算。然后将其保存在上面提到的2个直方图中，用于延迟。
根据磁盘上的数据生成分区大小和单元计数。每个sstable都会保留分区大小和写入时计算的细胞计数的直方图。当读取表的这个值时，它会合并来自所有sstables的统计数据，以生成百分位数计算中使用的表宽直方图。