| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\ |
|
| | |
| |
| |
| | |
messages to be recovered, due to mnesia not being running fast enough.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
o) Removed redundant rubbish from manager
o) Wired alarms straight to disk_queue (+ minor refactor)
o) Removed reduce/increase_memory_footprint from control and amqqueue
Testing shows that one of the reasons the memory estimates are off is because they only track messages in the queue - i.e. remove on deliver, not on ack. Watching ./scripts/rabbitmqctl list_queues name memory mode messages messages_ready messages_unacknowledged messages_uncommitted during various tests shows that acks are not getting through and so we actually need to track unacknowledged message size - i.e. remove on ack, not on deliver
|
| | | |
|
| | |
| |
| |
| | |
you are in all mixed mode, and then set one queue to disk, and then call increase_memory_footprint, you will indeed set that one queue back to mixed mode. And vice versa with mixed and decrease
|
| | |
| |
| |
| | |
guess the only reason for keeping the other counter which is the min number of messages the process has received between reporting memory, is that it's much faster to decrement that counter and ceq0 than do the time calculation for every single message.
|
| | |
| |
| |
| | |
process_info(memory,self()) for reasons outlined in the bug comments. The annoying thing about using a 10% change as the threshold is that it means you get many many more updates when the queue is empty because the % change is much greater.
|
| | |
| |
| |
| | |
queues were being started up in the wrong mode when in the "middle" mode...
|
| |\ \
| |/ |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
There was a choice here of either pushing all the txn accountancy into the mixed_queue and taking it out of queue_process or just passing in all the txn pending messages to the mode switch. I chose the latter because the queue_process is already the more readable of the two modules and I didn't want to further complicate the mixed_queue. Also, this way is a smaller API change and really not that much code.
Tests pass but I'm about to rewrite the test and bulk it up a bit. Also, running the previous tests - rabbitmq-java-client/build/dist$ sh runjava.sh com/rabbitmq/examples/MulticastMain -y 50 -r 100 -s 104857 -m 100 -z 120 - whilst running (reduce|increase)_memory_footprint is a good thing to do.
|
| | | |
|
| | | |
|
| |\ \
| |/ |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
An even better test (see parent commit message) is:
rabbitmq-java-client/build/dist$ sh runjava.sh com/rabbitmq/examples/MulticastMain -y 50 -r 100 -s 1048576 -m 100 -z 120
Rabbit will now happily just sit there and work away (again, run reduce_memory_footprint twice first) even though it's seeing 100MB new a second which is going to 50 consumers, so 5GB a second. Needless to say, go back a few revisions, and it blows up within seconds.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
it does seem to get emptied successfully.
So, using this revision, if you run:
rabbitmq-java-client/build/dist$ sh runjava.sh com/rabbitmq/examples/MulticastMain -y 10 -r 50 -s 1048576 -m 100 -z 120
then over the two mins, I see beam take between about 30% and 45% of my memory, once it's up and running.
Using the revision right after the API change, i.e. 9f0ee0399838, the same test tries to take between about 45% and 60% of my memory.
Don't forget to run:
rabbitmq-server$ ./scripts/rabbitmqctl reduce_memory_footprint
rabbitmq-server$ ./scripts/rabbitmqctl reduce_memory_footprint
before running the above test.
|
| | | |
|
| | |
| |
| |
| | |
multiple queues, eliminates the need for multiple reads, provided the /next/ copy of the message is requested before the previous copy of the message has been acked. Should reduce memory pressure.
|
| | |
| |
| |
| | |
means that the mixed_queue avoids unnecessary term_to_binary calls. Tests adjusted and whole test suite still passes
|
| | |
| |
| |
| | |
deciding when to report. This isn't quite good enough though because GC means the memory size fluctuates too much. Need to switch to just grabbing the size of the messages in the queue.
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
related to memory use when it's in disk only mode which could be used to estimate how much more memory is needed to switch to mixed mode
|
| | | |
|
| | |
| |
| |
| | |
longer be a repeat timer because once it's set were either going to receive the explicit sync call or we're going to timeout on message queue at which point we're no longer dirty and so we'll then cancel the timer....
|
| | | |
|
| |/ |
|
| | |
|
| |\ |
|
| | | |
|
| | |
| |
| |
| | |
standard unix variable which should be honoured
|
| | |
| |
| |
| | |
functions which I can't work out what to do about... Also cosmetic
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |\ \
| |/ |
|
| | | |
|
| | | |
|
| | |\ |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | |\ \
| | | |
| | | |
| | | | |
further qa is still required
|
| | | | | |
|
| | |\ \ \ |
|
| | | | |/
| | |/| |
|
