I have a very large backlog of particular.monitoring messages (1 million plus), could this be causing problems reading other queues?
All endpoints on a single machine share the same CPU, RAM, and disks. If one queue has a huge number of messages and processing a single message is also a heavy task then it can impact the performance of the other endpoints because it steals these shared resources.
If it actually has an impact depends on how many resources you have and if the other queues are (near) empty.
If you are affected, then you can lower the allowed concurrency:
NServiceBus 5 has a default concurrency of 1, NServiceBus 6 has a default concurrency equal to the number of cores of the machine.
If you have set the maximum concurrency to 1 and it is still impacting the other endpoints too much then you can apply throttling by rate limiting the incoming messages.
That doesn’t work for NServiceBus 6, but if you want to rate limit an NServiceBus 6 endpoint then you can do this by using the following package:
– Ramon
That many messages in the particular.monitoring queue sound like quite a lot.
Is it an expected? If your monitoring instance is not running and you want to cap the number of messages by their age there is an TTBR setting in the monitoring plugin that enables that:
Cheers,
Tomek
I didn’t notice the queue name was particular.monitoring, is monitoring running?
You can just purge the queue as this queue does not contain any business data and ServiceControl monitoring only keeps track of the last hour of data. Your queue probably contains data that is much older.
If you purge your queue, please also check the Transactional dead-letter messages under System Queues as that can contain these purged messages. Make sure that it doesn’t contain any undelivered business messages, and then you can purge the Transactional dead-letter messages too.
ps. Even if you do not purge these message and start the ServiceControl Monitoring service processing these message should go very very fast.
Hi Ramon
Thanks for the reply.
I don’t have the ServiceControl Monitoring so I guess it makes sense to put a cap on the particular.monitoring queue? But the whole issues I have is around the service that’s using nservicebus failing so I wanted to know if it could be linked to the large particular.monitoring queue.
Hi Tomek,
Thanks. My question is … can a large queue (particular.monitoring) affect other queues that use nservicebus? The system is hanging and only continues working after restarting the service (that reads from another queue).
If you do not have a monitoring instance then who is consuming these messages? If you are not consuming them you should just disable monitoring in your endpoints so that these messages are not sent.
Can you please share any error/exception data? You should have log files for your endpoints.
If could very well be that due to the large number of messages that you do not have enough storage.