Thanks for telling the story.<br><br>By the way, how much messages can now RabbitMQ handle easily?<br><br><div class="gmail_quote">2010/7/15 Ovidiu Deac <span dir="ltr"><<a href="mailto:ovidiudeac@gmail.com">ovidiudeac@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">There is one thing though which is wrong: if a memory limit is given<br>
rabbitmq should manage its memory such that it can continue working<br>
properly but doesn't accept any more messages. If the memory limit is<br>
above a certain level the queues should be closed and all the messages<br>
published become unroutable.<br>
<br>
This way it would accept connections which extract messages and thus<br>
would free that memory.<br>
<div><div></div><div class="h5"><br>
On Thu, Jul 15, 2010 at 10:51 PM, Ovidiu Deac <<a href="mailto:ovidiudeac@gmail.com">ovidiudeac@gmail.com</a>> wrote:<br>
> I found the problem: the memory limit was the default one which is 1.6<br>
> i.e. 40% out of 4GB. It seems the OS installed is 32bits and this is<br>
> why erlang doesn't see the full 6GB RAM.<br>
><br>
> Of course the system didn't work if it ran out of memory.<br>
><br>
> As soon as I changed vm_memory_high_watermark to 0.98 by putting<br>
> [{rabbit, [{vm_memory_high_watermark, 0.98}]}].<br>
> ... in /etc/rabbitmq/rabbitmq.config the problem was fixed<br>
><br>
> Thanks for the help.<br>
><br>
> ovidiu<br>
><br>
> On Thu, Jul 15, 2010 at 8:50 PM, Scott Brooks <<a href="mailto:scott@beamdog.com">scott@beamdog.com</a>> wrote:<br>
>> 200k messages, @ 300 bytes a piece is nothing.<br>
>><br>
>> I just ran a test and everything is fine for me.<br>
>><br>
>> Can you re-do the test? Also what are the specs on the server you are<br>
>> running the test on?<br>
>><br>
>> Scott<br>
>><br>
>><br>
>> On Thu, Jul 15, 2010 at 11:33 AM, Ovidiu Deac <<a href="mailto:ovidiudeac@gmail.com">ovidiudeac@gmail.com</a>> wrote:<br>
>>> First of all thanks for the answers. Second I'll explain the situation<br>
>>> a little better.<br>
>>><br>
>>> The big picture is like this: we receive orders from outside and they<br>
>>> are put in rabbit by our "gateway" and then routed by rabbit to the<br>
>>> processing modules. The whole business is about handling those<br>
>>> messages and if we are unable to receive messages from outside is very<br>
>>> bad so basically our gateway should be up all the time.<br>
>>><br>
>>> Normally all the orders coming in should be handled smoothly BUT if<br>
>>> something happens to the consumers and they have a downtime the<br>
>>> producer has no way to stop the incoming messages. Also we always want<br>
>>> to be able to accept messages because we are payed for each incoming<br>
>>> message.<br>
>>><br>
>>> Normally the system admin should handle the problem and restart the<br>
>>> consumers. As I was saying before, we are testing for the worst case<br>
>>> scenario, to see what the limits of RabbitMQ are. We want to see how<br>
>>> can we extend these limits to increase the time we have until the<br>
>>> queues get full.<br>
>>><br>
>>> From our calculations if rabbitmq could hold 500k messages up to<br>
>>> 300bytes each we would be pretty safe as that would give us enough<br>
>>> time to react. The 200k limit is a little tight.<br>
>>><br>
>>> ovidiu<br>
>>><br>
>>>> @Ovidiu:<br>
>>>> BUT, are you really sure you want what you are asking for? If I understand<br>
>>>> you correctly you want to allow outside producers (not under your control)<br>
>>>> to send persistant messages directly into your RabbitMQ and not have those<br>
>>>> producers back off?<br>
>>>><br>
>>>> Personally, I think that is not achievable. At some point your server ii><br>
>>>><br>
>>>> _______________________________________________<br>
>>>> rabbitmq-discuss mailing list<br>
>>>> <a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>
>>>> <a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
>>>><br>
>>>><br>
>>><br>
>>> s<br>
>>>> going to reject messages, and your producers must be able to deal with that,<br>
>>>> if, as you say, no messages are allowed to be lost.<br>
>>>><br>
>>>> Robby<br>
>>> _______________________________________________<br>
>>> rabbitmq-discuss mailing list<br>
>>> <a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>
>>> <a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
>>><br>
>><br>
><br>
_______________________________________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>
<a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Linkėjimai, Best Regards<br><br>Darius Damalakas<br>