[rabbitmq-discuss] RabbitMQ 2.3.1 high CPU usage & disks operations

Matthew Sackman matthew at rabbitmq.com
Tue May 3 22:19:55 BST 2011

Hi Raphael,

On Mon, Apr 25, 2011 at 03:12:07PM -0700, Raphael Simon wrote:
> Following up on this as we are still having the issue, I've pasted the
> output of etop for a broker in a 'good state' [1] vs. one in a 'bad state'
> [2]. You'll notice that broker1-1 (the one in 'bad state' i.e. using ~120%
> cpu compared to ~20% for the one in 'good state') is spending a lot of time
> in timers and reading from disk. Looking at the timer_server process on 1-1
> shows that it's mostly running rabbit_amqqueue:sync_timeout, this seems to
> be the culprit for the high cpu and disk ops. So what is the purpose of this
> timer? and why would it suddenly trigger more often or at least be more
> expensive to handle?

Interesting. Are you using confirms when publishing msgs? If you are,
and the msgs are published persistent, then there could be an awful lot
of fsyncs being scheduled which could possibly cause a cascade. Maybe. I
can't come up with any better cause... Or maybe an awful lot of
transactions with persistent msgs?


More information about the rabbitmq-discuss mailing list