问题标签 [hdrhistogram]

我一直在使用 Java 中的 HdrPercentile 库来监视系统中某些数字的分布。

我决定走捷径并使用 outputPercentileDistribution 让 HdrHistogram 向我展示它对我的数据的看法。

输出很有用，但我很难理解 HdrHistogram 如何控制它打印的桶数。

数字由函数参数控制

按百分比生成直方图数据值分布的文本表示。分布以指数增加的分辨率输出，每个指数减少的半距离包含 dumpTicksPerHalf 百分位报告滴答点。

percentileTicksPerHalfDistance 每个指数递减半距离的报告点数

我不明白它是如何被翻译成桶的。我确实注意到，我通过的数字越大，我得到的桶就越多。

有人可以准确解释存储桶是如何设置的吗？

我正在使用 HdrHistogram java 库，但没有得到所需的输出。你能帮我理解图书馆或预期值有错误吗？

在这种情况下，我期望输出为 1000000，但实际输出为 1000003

为什么会这样。我的 Maven 设置是：-

我正在使用 HDR 直方图的 Java 实现：

我注意到即使样本数为 1，最小值和最大值也会有所不同：

我在直方图代码中看到以下片段：

（那是在GitHub中）

我的问题是：为什么我们不能简单地返回记录minNonZeroValue？

在使用 HdrHistogram 进行基准测试后，我得到了这个数字作为值：

142.22182267674.623

那应该是纳秒，但那是什么数字？

这是基准测试的一些结果。这不是两个数字合二为一，是的，我学过数学，但没有像这样结构的数字....

我正在使用 LatencyUtils 包来跟踪和报告跨测量的延迟行为：

• https://github.com/LatencyUtils/LatencyUtils/blob/d8f51f39f6146e1ad9a263dc916bcbc0ec06e16d/src/main/java/org/LatencyUtils/LatencyStats.java#L196

通过这种方法记录时间，时间单位应该是纳秒，但在我的例子中，记录的时间是以毫秒为单位的。我想知道是否有更好的方法以毫秒为单位记录时间？

我现在使用的解决方案是将所有记录的时间乘以一百万。但是我还是希望结果以微秒为单位，所以对于我得到的结果，我除以一百万。

的默认构造函数LatencyUtil是这样的：

所以，事实上，最低的可跟踪延迟LatencyUtil也是纳秒级的。如果我以毫秒为单位放一个值，恐怕会影响记录的结果。

最近开始尝试在 C++ 中使用 hdr_histogram。像unix中的魅力一样工作。但是相同的程序在 Windows (Visual Studio 2017) 中中断。调用 hdr reset (hdr_interval_recorder.inactive) 时引发“访问冲突”。inactive 是 NULL，而在 unix 中不是。在此之前，我确实在 hdr_interval_recorder 上调用了 hdr_interval_recoder_init_all。关于我应该开始看什么的任何建议？

我尝试运行一个非常简单的使用 java 9 模块的 gradle 项目，但我收到以下错误。

这是https://github.com/vad0/test_modules。主类基本上什么都不做。

它只使用一个依赖项：HdrHistogram。我根据官方 gradle 教程https://docs.gradle.org/current/samples/sample_java_modules_multi_project.html在 build.gradle 中包含了这个神奇的命令。

整个 build.gradle 看起来像这样。

module.info 看起来像这样

我已经阅读了许多关于 Jigsaw 的教程和一大堆与之相关的 stackoverflow 问题，但仍然无法使这个简单的示例工作。我如何解决它？

谢谢

每次执行此时间公园时，我都试图以毫秒为单位存储时间。然后我想用 HdrHistogram 来表示延迟。

但是，我无法将时间存储在我的数组中。请问，你能提供任何帮助吗？

我们的团队正在使用 HdrHistograms 监控我们的应用程序的延迟。当我将异步分析器附加到它时，所有百分位数都会急剧增加。

操作系统：Red Hat Enterprise Linux 8.1 版（Ootpa）

JVM：11.0.8-zing_20.08.2.0-b2-product-linux-X86_64

如果我使用标志 -i 1000 -t 附加探查器会发生这种情况：

如果我使用标志 -i 100000 -t 附加探查器会发生这种情况：

降低采样频率显然会降低开销，但仍然很大。我有两个问题：

1. 除了降低采样频率之外，还有其他方法可以减少分析开销吗？也许有一些神奇的内核/JVM标志？
2. 这种开销是否会严重扭曲配置文件本身？

谢谢