diff options
| author | Matthew Sackman <matthew@lshift.net> | 2009-07-09 15:30:55 +0100 |
|---|---|---|
| committer | Matthew Sackman <matthew@lshift.net> | 2009-07-09 15:30:55 +0100 |
| commit | 30d8f863ab27e650d57559b1fd20ae43a4d709f8 (patch) | |
| tree | acd712ad173064a3fccccec2777c2e5d6e6a86fd /packaging/common | |
| parent | efba2704f58ed58c8e0b7310eeff7974024e0177 (diff) | |
| parent | 40b218b9469666282e6fb4b5c075ad3b37b9b6b8 (diff) | |
| download | rabbitmq-server-git-30d8f863ab27e650d57559b1fd20ae43a4d709f8.tar.gz | |
merging in from 21087. In testing, observed oscillation - with lots of queues, give 2 queues the same length such that they can't both fit in memory, and slowly trickle in messages. As each one gets a message, it'll force the other one out to disk (the other one will either be in the hibernating or lowrate groups). This is bad. Therefore, adjusted the conditions under which we bring a queue back in from disk to exclude queues that are either hibernating or low rate (don't forget, even a list_queues will wake up a queue and cause it to report memory). If you have two fast queues then neither of them will be in the groups of low rate or hibernating queues, so neither will be candidates for eviction so the problem doesn't exist there, instead, if they need more memory and can't fit in ram then they'll evict themselves to disk rather than anyone else.
Also realised that a million queues isn't unreasonable, so minimum number of tokens in the system should be more like 1e7 if not higher.
Diffstat (limited to 'packaging/common')
0 files changed, 0 insertions, 0 deletions
