2

我正在为我们的一个用例对 Chronicle 队列进行基准测试，并注意到 ExcerptTailer 的 readDocument() API 创建了太多垃圾！JFR 显示，该过程在下面的堆栈中花费了大约 66% 的时间。

我使用的是哪个版本的 Chronicle Queue？

net.openhft：编年史队列：4.5.9

我如何创建队列？

queue = SingleChronicleQueueBuilder.binary(filename).build();
appender = queue.acquireAppender();
tailer = queue.createTailer();

//Snippet to read
tailer.readDocument(r -> {
            //Reading some context here

        });

产生了多少垃圾？

3 分钟大约 11 GB

堆栈跟踪

Stack Trace TLABs   Total TLAB Size(bytes)  Pressure(%)
byte[] java.lang.StringCoding$StringEncoder.encode(char[], int, int)    167 6,593,171,600 52.656
   byte[] java.lang.StringCoding.encode(String, char[], int, int)   167 6,593,171,600   52.656
      byte[] java.lang.String.getBytes(String)  167 6,593,171,600   52.656
         String[] java.io.UnixFileSystem.list(File) 167 6,593,171,600   52.656
            String[] java.io.File.list()    167 6,593,171,600   52.656
               String[] net.openhft.chronicle.queue.impl.single.SingleChronicleQueue.getList()  167 6,593,171,600   52.656
                  void net.openhft.chronicle.queue.impl.single.SingleChronicleQueue.setFirstAndLastCycle()  167 6,593,171,600   52.656
                     int net.openhft.chronicle.queue.impl.single.SingleChronicleQueue.firstCycle()  167 6,593,171,600   52.656
                        long net.openhft.chronicle.queue.impl.single.SingleChronicleQueue.firstIndex()  167 6,593,171,600   52.656
                           boolean net.openhft.chronicle.queue.impl.single.SingleChronicleQueueExcerpts$StoreTailer.next(boolean)   167 6,593,171,600   52.656

我还尝试了什么？

我使用 JitWatch 并将用于转义分析的字节码大小从 150 字节增加到 516 字节。我注意到 readDocument 方法是 JIT 编译的。

对下一步有什么建议吗？

4

1 回答 1

2

这只发生在忙轮询并且没有消息时。您可以添加一个虚拟消息来防止这种情况。解决方法已添加到更高版本。

于 2017-09-08T21:10:23.390 回答