Bitcoin Forum

Bitcoin => Development & Technical Discussion => Topic started by: Transisto on March 24, 2013, 03:18:27 PM



Title: Dedicated bitcoind node, 1gb ram ="errors" : "EXCEPTION: St9bad_alloc \nstd::bad
Post by: Transisto on March 24, 2013, 03:18:27 PM
Code:
{
    "version" : 80100,
...
    "blocks" : 227829,
    "connections" : 49,
 ...
    "errors" : "EXCEPTION: St9bad_alloc       \nstd::bad_alloc       \nbitcoin in ProcessMessages()       \n"
}
I've been told this meant it was low on memory.

This is a on dedicated bitcoind node on a ubuntu VPS with 1024mb and 2048 brustable ram.

I usually reach 950mb ram when at about 36 connections.

Since all I want it to do is seed the blockchain as much as it can, should I lower the connection number to 36 even if it sometime goes to 56 without any apparent issue other than that error message.



Title: Re: Dedicated bitcoind node, 1gb ram ="errors" : "EXCEPTION: St9bad_alloc \nstd::bad
Post by: nagnagnag2 on March 24, 2013, 06:16:59 PM
I did get that myself just a couple of hours ago.

My bitcoind instance had turned itself off (or crashed - don't know), so I had to restart it.

1 536 Mb of ram.

Running bitcoind on the main net and on the testnet...



Title: Re: Dedicated bitcoind node, 1gb ram ="errors" : "EXCEPTION: St9bad_alloc \nstd::bad
Post by: Mike Hearn on March 24, 2013, 06:45:00 PM
Yes, bitcoind memory usage seems to grow fairly steadily at the moment. I spent some time with a heap profiler and it's not obviously a leak - possibly it's a side effect of the huge send/receive buffers in the code so the more peers you accumulate the more RAM is required.

I'm testing some optimizations by sipa to the networking code on my own VPS now. That one has a hard cap of 1gig of RAM, but that's way more than should really be needed. Bitcoin should work fine in just a few hundred megs, tops.


Title: Re: Dedicated bitcoind node, 1gb ram ="errors" : "EXCEPTION: St9bad_alloc \nstd::bad
Post by: twobitcoins on March 24, 2013, 07:21:45 PM
Memory usage is pretty stable for me when not downloading blocks, though it could be lower.  During initial block download, memory usage can grow without limit due to mapOrphanBlocks.  More details are in issue 2353 (https://github.com/bitcoin/bitcoin/issues/2353#issuecomment-14806541).


Title: Re: Dedicated bitcoind node, 1gb ram ="errors" : "EXCEPTION: St9bad_alloc \nstd::bad
Post by: Transisto on March 24, 2013, 10:46:12 PM
I'm supprised by the ressource required.

Fixing this exessive ram usage could mean a lot more seeding node and much faster blockchain download.

One of the most expensive part of VPS is ram, (beside the 500gb+ in monthly upload I can live with)


Title: Re: Dedicated bitcoind node, 1gb ram ="errors" : "EXCEPTION: St9bad_alloc \nstd::bad
Post by: gmaxwell on March 24, 2013, 10:52:03 PM
Yes, bitcoind memory usage seems to grow fairly steadily at the moment.
I haven't seen that— a node with 8 connections appears pretty stable at about 300MB res, nodes with many in-bounds use about a gig— which is the roughly the same as it was 6 months ago.

Are you sure the people here aren't just running out of address space on 32 bit systems?


Title: Re: Dedicated bitcoind node, 1gb ram ="errors" : "EXCEPTION: St9bad_alloc \nstd::bad
Post by: Transisto on March 24, 2013, 10:57:08 PM
Yes, bitcoind memory usage seems to grow fairly steadily at the moment.
I haven't seen that— a node with 8 connections appears pretty stable at about 300MB res, nodes with many in-bounds use about a gig— which is the roughly the same as it was 6 months ago.

Are you sure the people here aren't just running out of address space on 32 bit systems?
Maybe someone can report on memory usage for a node with 100+ nodes,

32bit ? I don't know, the OS is 64bit.


Title: Re: Dedicated bitcoind node, 1gb ram ="errors" : "EXCEPTION: St9bad_alloc \nstd::bad
Post by: kjj on March 25, 2013, 03:38:10 AM
I have a 32 bit box running with less than 1 GB of ram.  It has two instances of bitcoind running, one with 1 connection, and one with 60 (nearly or all incoming).

I think the real problem is running into some artificial limitation in lousy VPS software.