> 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.
Are you using transactional message sends? Page transaction info will be kept on broker side until cleared by consumers. I guess additional transaction info overhead and messages themselves caused heap usage to limit exceed and slowed down the broker. If so, you can try non transactional sends. kter <[email protected]> 于2019年11月1日周五 下午9:11写道： > 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 >
