Hi Tim, Jean-Baptiste,
I've worked out what the issue is/was:
I have a Camel route which splits groups of 32 elements in a JSON array in
to 32 individual messages. These are small and persistent and so written
to disk when there's a durable subscription in place, causing the high I/O
load.
Even
Peter,
Three quick points to consider:
1. It's possible to provision additional IOPS on your EBS volumes to get
more write throughput, which might be cheaper than EFS. You'd have to run
the numbers for your particular use case, but it's worth evaluating.
2. There are several classes of EBS volume,
Hi,
EFS works fine and it's really convenient if you want master/slave
setup. The only drawback is that it can costs a lot ;) (I don't if you
evaluate the price of using EFS). If you don't need master/slave, EFS is
not required (the local fs performance can be good enough depending the
kind of EC2
Hi JB
I was using a EBS (local) partition when I saw the horrendous I/O
throughput. During testing over the last hour or so, I've mounted an EFS
(for those who don't grok Amazon AWS, Elastic File System: basically an NFS
mount) target and symlinked the kahadb directory over to it.
My current Kah
Hi Peter,
The most important is the I/O rate/throughput. I'm also using some
brokers on EC2 (some using JDBC store, some using kahadb store).
What's the filesystem ? EFS or "local" EC2 ?
What's your current kahadb configuration in activemq.xml ?
Just a note: 5.15.9 got major improvements on kah
All,
I have a feed of 110 messages/second of about 150 bytes each which I'm
routing through a default-settings ActiveMQ 5.15.8 server and sending on to
a topic. Everything works fine until I set up a durable subscription, at
which point iostat (Ubuntu 18.04LTS) reports about 300tps and about 2-3
