Question

我在其中一个用例中记录了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编译的。

关于下一步的任何建议？

Answer 1

仅在忙碌轮询且没有消息时才会发生这种情况。您可以添加虚拟消息以防止这种情况。在以后的版本中添加了一种解决方法。

Chronicle Queue StoreTailer.next（）会产生大量垃圾

1 个答案: