FileChannel.lock运行了很长时间

Question

所以我有一个简单的代码，我在那里监听jms msg并将其写入不同的编年史队列，具体取决于修复标记。

public void onEvent(InputEvent inputEvent) {
    String msg = ((SimpleInputEvent) inputEvent).getMessage();
    int start = msg.indexOf("\u000155=");
    if (start == -1){
        // dropping it
        return;
    }
    char symbol = msg.charAt(start+4);
    for (int i = m_ranges.length - 1; i >= 0; i --){
        if (symbol >= m_ranges[i]){
            m_appenders[i].writeText(msg);
            break;
        }
    }
}

现在，我正在进行一些性能测试，我发现它有这种配置文件

主线程正在运行上述功能。 我们可以看到FileChannel.lock正在运行30秒！我不确定它在做什么。我像这样创建了队列

        m_queues[j] = SingleChronicleQueueBuilder.binary(path + "_" + m_ranges[j]).build();
        m_appenders[j] = m_queues[j].acquireAppender();

谢谢！

在阅读了更多内容之后，我将blockSize增加到512Mb，这是我在此测试中永远无法达到的。但是，我的性能测试仍然存在瓶颈。特别是，sar显示

我将bufferSize增加到比我写入cq4文件更大的代码，这段代码永远不应该启动。但我仍然看到我的系统存在一些瓶颈。如果我打开sar，我会看到

05:05:41 AM tps rtps wtps bread / s bwrtn / s .... 上午05:10:12 714.14 0.00 714.14 0.00 6901.01

05:05:41 AM DEV tps rd_sec / s wr_sec / s avgrq-sz avgqu-sz await svctm％util ... 上午05:10:12 rootvg-lvar 422.00 0.00 3376.00 8.00 0.10 0.23 0.00 0.20

我该怎么做才能避免大量写入桌面？

Answer 1

假设您正在运行最近的Linux，您在SAR中看到的是内核将页面缓存中的页面写入磁盘。

Chronicle Queue使用内存映射文件，而不是对磁盘进行任何“直接”写入。因此，操作系统可以控制来自队列文件的数据何时实际持久存储到存储。

如果希望减小这些写入的大小，可以尝试将内核配置为以较短的间隔刷新页面。