[rabbitmq-discuss] RabbitMQ 1.7.2 with Erlang R13B04 crashes after several hours running MulticastMain from 1.7.2

[Matthew Sackman]

Hi John,

On Fri, Apr 02, 2010 at 05:01:14PM +0100, Matthew Sackman wrote:
> The "Memory limit set to 819MB." shows that rabbit really did detect
> 4GB of Ram in there, which is interesting for a Windows system - it
> suggests you're running a 64-bit Erlang.

No, no it doesn't. I can't do maths...

819/0.4 = 2048.

On Mon, Apr 05, 2010 at 03:20:26PM +0200, John Apps wrote:
> Here you go:
> >>>os:type().
> {win32,nt}
> >>>erlang:system_info(wordsize).
> 4
> 
> >>>Also, if you start up rabbit, and in the rabbit shell, type:
> >>>vm_memory_monitor:get_total_memory().
> 4284735488

Right, this all makes sense. You're running a 32-bit Erlang, which
depending on all sorts of fairly ridiculous issues with Windows, means
that the biggest amount of memory that Windows will allocate to Erlang
(or any 32 bit process) is sometimes 2GB and sometimes 3GB. Under 32-bit
windows, we take the minimum of the detected RAM (4GB in your case), and
2GB (32bit on Windows). The 0.4 scaling is done after that, which is why
we end up with 819MB.

It would then seem that the malloc failed because it would have taken
the erlang process above the 2GB or 3GB limit (whichever your version of
Windows applies to 32-bit programs). The correct thing to do in this
case is to lower the 0.4 and try again, I'm afraid. Slightly more
documentation is available at
http://www.rabbitmq.com/extensions.html#memsup

I am surprised that even inspite of the 0.4 scaling, you still managed
to get Rabbit to go above the address space limit. Flow control should
have kicked in, stopping the producer. The consumer could still continue
but clearly something happened which caused Erlang to require more
memory than Windows could supply it with.

Does it still happen if you lower the -n parameter in your tests?

Matthew