iam*_*trk 5 cassandra nodetool cassandra-2.0 cassandra-3.0
当我运行“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
Run Code Online (Sandbox Code Playgroud)
有人可以解释一下这些是如何计算的吗?我理解 %le 概念,但我想知道计算上述结果需要考虑多少次读/写。
下雪了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”列是读取时触及的 sstable 数量。“感动”的含义在CASSANDRA-13120中发生了变化。以前,如果检查 sstable 上的 Bloomberg 意味着可能存在磁盘 IO,那么它会被包含在内,但它只会按令牌范围和时间戳过滤掉内容。现在,如果布隆过滤器从读取中排除 sstable,则它不会被计算在内。然后将其保存在上述延迟的 2 个直方图中。
分区大小和单元格计数是根据磁盘上的数据生成的。每个 sstable 都保留分区大小的直方图和写入时计算的单元格计数。当读取表的此值时,它会合并所有 sstable 的统计信息以生成在百分位计算中使用的表宽直方图。
| 归档时间: |
|
| 查看次数: |
1513 次 |
| 最近记录: |