FileChannel.lock running for a long time - chronicle

Question

So I have a simple code where I listens to jms msg and writes it to different chronicle queue, depending on the fix tag.
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;
}
}
}
Now, I'm running some performance test and I see that it has this kind of profile
The main thread is running the above function.
And we can see the FileChannel.lock is running for 30 seconds straight! I'm not sure what it's doing. I created the queue like this
m_queues[j] = SingleChronicleQueueBuilder.binary(path + "_" + m_ranges[j]).build();
m_appenders[j] = m_queues[j].acquireAppender();
Thanks!
After reading more, I increased the blockSize to 512Mb which I will never reach in this test. However, I still reach a bottleneck in my performance test. In particular, sar shows
I increased the bufferSize to larger than I would have written to cq4 file this code should never kick in. But I still see some bottleneck in my system. If I turn on sar, I see
05:05:41 AM tps rtps wtps bread/s bwrtn/s
....
05:10:12 AM 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 AM rootvg-lvar 422.00 0.00 3376.00 8.00 0.10 0.23 0.00 0.20
what should I do to avoid a big chunk of write to desk?

Answer 1

Assuming you're running a recent Linux, what you are seeing in SAR is the kernel writing pages from the page cache to your disk.
Chronicle Queue uses memory-mapped files rather that making any 'direct' writes to disk. So the operating system is in control of when data from a queue file is actually persisted to storage.
If you wish to reduce the size of those writes, you can try to configure the kernel to flush pages at a shorter interval.