[erlang-questions] mnesia memory usage on 32 and 64 bits machines

50 views
Skip to first unread message

franz

unread,
Dec 31, 2010, 6:46:02 AM12/31/10
to erlang-q...@erlang.org
Hello everybody.
I would like to know your opinions about a load test I'm doing, whose
result quite shocked me.
Briefly, I created a mnesia ets table and inserted 50000 records into it.
I tried this bulk load on two machines: the first, say it A, running a
64bits kernel on a 64 bits machine, the second, say it B, running a
32bits kernel on a 64 bits machine.
On A the records occupy 202707450 words of mem, and misuring the RAM
consumption before and after the insertion I know that they occupy 1560Mb.
On B the records occupy 202707473 words of mem, with a RAM consumption
of 795Mb.
On one hand this makes sense, because as far as I know a word of mem on
a 32bits machine is 4 bytes, 8 on a 64bits machine. But does this mean
that having a 64 bits kernel doubles the memory usage?!?
Thank you all and happy new year,
franz


________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-questio...@erlang.org

Attila Rajmund Nohl

unread,
Dec 31, 2010, 7:01:24 AM12/31/10
to erlang-questions
2010/12/31, franz <fan...@tiscali.it>:
[...]

> On one hand this makes sense, because as far as I know a word of mem on
> a 32bits machine is 4 bytes, 8 on a 64bits machine. But does this mean
> that having a 64 bits kernel doubles the memory usage?!?

Actually this doesn't depend on the kernel, this depends on the Erlang
VM (i.e. userspace) using 32 bit or 64 bit. Generally 64 bit
applications use a lot more memory.

Brian Candler

unread,
Jan 1, 2011, 11:34:02 AM1/1/11
to franz, erlang-q...@erlang.org
On Fri, Dec 31, 2010 at 12:46:02PM +0100, franz wrote:
> I would like to know your opinions about a load test I'm doing,
> whose result quite shocked me.
> Briefly, I created a mnesia ets table and inserted 50000 records into it.
> I tried this bulk load on two machines: the first, say it A, running
> a 64bits kernel on a 64 bits machine, the second, say it B, running
> a 32bits kernel on a 64 bits machine.
> On A the records occupy 202707450 words of mem, and misuring the RAM
> consumption before and after the insertion I know that they occupy
> 1560Mb.
> On B the records occupy 202707473 words of mem, with a RAM
> consumption of 795Mb.
> On one hand this makes sense, because as far as I know a word of mem
> on a 32bits machine is 4 bytes, 8 on a 64bits machine. But does this
> mean that having a 64 bits kernel doubles the memory usage?!?

When you boot a 32-bit kernel, your processor is running in a
backwards-compatibility 32-bit mode, as an i386 processor. The x86_64 mode
is essentially a different processor, with different instruction set and
register model.

And if you boot into DOS, you'll be running 16-bit "real mode" :-)

But in summary: booting a 32-bit OS turns your machine into a 32-bit PC.

Regards,

Brian.

Ulf Wiger

unread,
Jan 2, 2011, 8:08:33 AM1/2/11
to fan...@tiscali.it, erlang-q...@erlang.org

On 31 Dec 2010, at 12:46, franz wrote:

> But does this mean that having a 64 bits kernel doubles the memory usage?!?

As a general rule, running with 64-bit Erlang doubles the memory footprint.
The exception is binaries, which use only marginally more space.

The OTP team is working on a "half-word" emulator, which uses a 32-bit
memory space for the process heaps, but keeps other data (e.g. ETS and
binaries) in 64-bit space. This VM is still experimental, but can be built
with configure --enable-halfword-emulator

BR,
Ulf W

Ulf Wiger, CTO, Erlang Solutions, Ltd.
http://erlang-solutions.com

franz

unread,
Jan 21, 2011, 4:52:47 AM1/21/11
to erlang-q...@erlang.org
I admit I was tempted by the 32-bits architecture. As I'm developing a
mnesia-centric distributed application I thought that using 32-bits
machine would have reduced the ram consumption and the access speed. So
I developed some tests to be run on two identical servers, one running a
32-bits kernel and erlang, the other 64-bits.
And everything went fine, until I bumped into the "maximum heap size for
32-bit machines", which I was unaware of: when a mnesia table exceeds
3GB erlang crashes saying <<erlang eheap_alloc: Cannot allocate xxx
bytes of memory (of type "heap")>>.
In conclusion, for anyone wondering, I think I'm going 64.
Regards,
franz

Hynek Vychodil

unread,
Jan 21, 2011, 7:06:42 AM1/21/11
to fan...@tiscali.it, erlang-q...@erlang.org
If I remember right There was announced nice optimization of Erlang
process heap using 32 "pointers" on 64-bit architecture on SFO Erlang
Factory last year and I believe it is included in R14B version. Anyway
I'm not sure and didn't verify.

--
--Hynek (Pichi) Vychodil

Analyze your data in minutes. Share your insights instantly. Thrill
your boss.  Be a data hero!
Try GoodData now for free: www.gooddata.com

Nicholas Frechette

unread,
Jan 24, 2011, 10:01:40 AM1/24/11
to Hynek Vychodil, fan...@tiscali.it, erlang-q...@erlang.org
The 32 bit vs 64 bit dilemma is pretty old now. You can see 64bit taking
generally more memory pretty much everywhere. I remember testing ubuntu 32
bit vs 64 bit and the 64 bit version used a good 1.5-1.7 times more memory
on a vanilla install (1year ago).
But as mentioned in the thread before, this can be mitigated to some extent
if you manage the types properly at runtime, incurring the extra cost only
on pointers and the extra alignment/padding required by them.
Since my server is a fairly old amd 64bit with only 1.5gb ram, the extra
memory I save from running in 32bit helps quite a bit. With 2gb+ ram, the
line gets blurry and it isn't really usefull to stick with 32bit. Obviously,
with 4gb+ you need 64 bit...
Your choice should depend on your hardware and on the applications you run
on it. Simple as that, profile and see. Depending on your data layout and
what you do with it, you might or might not see a noticeable performance
difference (by that I mean +- 5%). I believe, generally, 64bit to be a bit
slower due to the extra memory cost generating more cache misses.

Nicholas

Reply all
Reply to author
Forward
0 new messages