> ...we couldn't tune Artemis to achieve a tolerable impact from paging.
What did you try tuning?
Did you gather any metrics from the broker during the slow-down (e.g. GC
logging, thread dumps, etc.)? If so, what did you find?
To be clear, paging is meant to be a palliative measure used sparingly
(i.e. when absolutely necessary). At 50K msgs/sec over 24 hours you'll have
over 4 billion messages in the queue and (as you note) almost 1TB of paged
data. What measures are you taking to ensure the consumers will be able to
catch up and clear that backlog? If the backlog is never cleared then the
address will likely be paging permanently which is not really the way the
broker was designed to be used.
Justin
On Fri, Nov 1, 2019 at 8:11 AM kter <
[hidden email]> wrote:
> We are currently running some performance tests on Artemis. Our use case is
> deploying a single Artemis node and publish a moderate number of messages
> (in the order of 50K messages per second) from multiple producers. We need
> to allow for durable consumer to be disconnected for up to 24hrs. We can't
> allow for messages to be dropped or producers being blocked.
>
> We observed that Artemis goes into paging mode and eventually the ingestion
> rate becomes unacceptably low and producers' time out when publishing. We
> think we can't avoid paging in such scenarios but we couldn't tune Artemis
> to achieve a tolerable impact from paging.
>
> Currently paging starts to become unacceptable when we reach approx. 2.56
> GB
> of unack'd messages using global-max-size of 6GB and page-size-bytes of -1.
> Rates are dropping to below 100 msg/s and eventually result with timeouts
> at
> the producer.
>
> Can anyone advise on how we might stretch Artemis to our requirements and
> get a more sustainable rates whilst paging is happening? Keep in mind that
> due to our requirements we would see around 800GB of messages written in a
> period of 24hrs
>
>
>
> --
> Sent from:
>
http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html>