This post "Symfony2 and RabbitMQ: lessons learned" does a nice job of explaining the problem (replace Symfony with Magento and it's still valid);
Because the consumer is one process that keeps running, that also
means that the service container and stuff keeps existing in memory.
When you’ve done some queries the database connection keeps open in
the background. And if it’s quiet on our queue, it may take some time
before we reach the message limit. If that time exceeds the
connect_timeout of your MySQL server, you’ll run into the warnings and
errors about lost connections.
Of course we should close the connection after the message is
processed or could try catch for Doctrine DBAL connection exceptions
or increase the connect_timeout setting but thats just denying the
real problem. Running consumers with a booted Symfony2 kernel just
doesn’t work so well.
So in short; when the queue isn't (very) busy, the MySQL connection stays open for a longer period thereby exceeding MySQL's timeout. When the queue is busy however, it'll hit the message limit for one connection and create a new connection, avoiding the timeout.
Two short term options;
1. Raise the MySQL timeout (but to what? that depends on how 'busy' your system is).
2. Lower the message limit per connection. I'm not sure how to do this.
I don't know about a long-term solution where we can both tailor the not-so-busy moments and the busy moments and avoid the time-out altogether without sacrificing performance in busy moments.
Edit; after re-reading your initial post and understanding the issue better, I now see you already realized exactly this.