Bitcoin Forum
December 05, 2016, 02:43:40 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2]  All
  Print  
Author Topic: Multiple bitcoind on one machine  (Read 5112 times)
wumpus
Hero Member
*****
qt
Offline Offline

Activity: 798

No Maps for These Territories


View Profile
August 08, 2011, 10:42:32 AM
 #21

The core development team is actively working against this goal
That's simply not true. The recent WalletDB refactoring made it possible to run multiple wallets in one process with only a few changes.

Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through FileBackup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
1480949020
Hero Member
*
Offline Offline

Posts: 1480949020

View Profile Personal Message (Offline)

Ignore
1480949020
Reply with quote  #2

1480949020
Report to moderator
1480949020
Hero Member
*
Offline Offline

Posts: 1480949020

View Profile Personal Message (Offline)

Ignore
1480949020
Reply with quote  #2

1480949020
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
payb.tc
Hero Member
*****
Offline Offline

Activity: 812



View Profile
August 08, 2011, 01:01:08 PM
 #22

just one reason of many, i'd say.

Do share the other reasons as they come to you.

I don't see how what you've said so far is a problem.

Don't take me the wrong way, I am genuinely interested in where the existing functionality fails to suffice Smiley

okay well here's one more reason i can think of... let's say there are TWO types of ways a site can use bitcoin:

1) the kind of site where new temporary addresses are constantly being generated for incoming payments, eg. btcflip.com
2) the kind of site where there is only ever 1 permanent address generated per customer (I think tradehill might be starting to do this).

for a site in category 1, it's wallet.dat is going to be constantly growing day by day, hour by hour, and will probably need to be replaced with a fresh one periodically, so that the site isn't running off a 100mb wallet file. These are just 'temporary' payment addresses, 99% of which might not have ever even had payments sent to them.

the site in category 2 might have 1000 customers, but it's wallet.dat could have as little as 1000 addresses and not need periodically replacing. Indeed for this kind of site replacing the wallet would be a bad thing, as each customer has been given his 'personal' address for that site.

now you tell me, what would be the best way to run these two types of sites on the same server?
payb.tc
Hero Member
*****
Offline Offline

Activity: 812



View Profile
August 08, 2011, 01:07:57 PM
 #23

I don't see how what you've said so far is a problem.

no sub-accounts?

the documentation basically recommends that accounts should be used to organise customers, say alice and bob.

so under normal circumstances your wallet file might have:

[alice]=>0.5
[bob]=>1.3

but let's say you have a second website which has customers alice and jane, but the catch is, it's NOT THE SAME ALICE Smiley

[alice]=>5000
[jane]=>20

so the only way to get around this is to add prefices to account names to designate what site they're customers of:

[a-alice]=>0.5
[a-bob]=>1.3
[b-alice]=>5000
[b-jane]=>20

would be much better organised with sub accounts:

[site a]=>1.8,
(
   [alice]=>0.5
   [bob]=>1.3
)
[site b]=>5020,
(
   [alice]=>5000
   [jane]=>20
)


actually, even if it was the same alice, you wouldn't want her to log in to site a or b and see her balance as 5000.5  ...those balances should remain separate.
jfreak53
Sr. Member
****
Offline Offline

Activity: 297



View Profile WWW
August 17, 2011, 03:35:55 PM
 #24

We run 12 to 15 per server depending on the load of each.  Not so much for Ram, each one takes about 150MB of ram total per user, but we have it limited also.  But more for the IO, it really uses a lot and more just seems to bog down the server we have noticed.

We used the same basic technique in the second reply to this thread.

"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -Benjamin Franklin 1755
█ █ http://www.microthosting.com -- Free reseller web hosting, OpenVZ-XEN-HVM VPS', ATOM Dedicateds!
2112
Legendary
*
Offline Offline

Activity: 1708



View Profile
August 17, 2011, 06:05:15 PM
 #25

But more for the IO, it really uses a lot and more just seems to bog down the server we have noticed.
If you know how to recompile you can try disabling memory mapping in the calls to db->open. The flag is DB_NOMMAP. It could slightly improve the disk cache hit ratio and it will greatly improve TLB hit ratio, especially on the virtualized servers.

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
jfreak53
Sr. Member
****
Offline Offline

Activity: 297



View Profile WWW
August 18, 2011, 02:05:02 AM
 #26

We will give that a try since we compile our own anyways, I will shoot that over and see if it helps some, thanks.

Since we're on the subject, any idea where to look to lower memory consumption off the top of your head?

"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -Benjamin Franklin 1755
█ █ http://www.microthosting.com -- Free reseller web hosting, OpenVZ-XEN-HVM VPS', ATOM Dedicateds!
2112
Legendary
*
Offline Offline

Activity: 1708



View Profile
August 18, 2011, 03:21:10 AM
 #27

Since we're on the subject, any idea where to look to lower memory consumption off the top of your head?
For the managed hosting environment (multiple bitcoind each with its own wallet, but reasonably good security) I would work as follows:

1) create a separate DBENV for the blkindex.dat
2) convert stdio.h access to blkNNNN.dat into DB access to additional named databases inside blkindex.dat, which already supports multiple databases, take care that block insertion is idempotent
3) convert the new environment from (1) from direct calls into RPC calls
4) run berkeley_db_svc RPC server serving a single copy of blockchain inside blkindex.dat for all the client bitcoin-daemons, each of which is only managing its own wallet in a separate (original) DBENV

This modification will give you best bang for your development buck in the reasonably secure managed hosting environment.

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
jfreak53
Sr. Member
****
Offline Offline

Activity: 297



View Profile WWW
August 20, 2011, 03:02:31 PM
 #28

Very nice idea 2112, I'll have our Devs look into it for integration.

"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -Benjamin Franklin 1755
█ █ http://www.microthosting.com -- Free reseller web hosting, OpenVZ-XEN-HVM VPS', ATOM Dedicateds!
tolazy
Full Member
***
Offline Offline

Activity: 196


View Profile
December 18, 2015, 09:46:38 PM
 #29

The overhead can be stupendous though.

You mean as in ram usage or are you talking about something else?

i was able to get 2 running successfully for a while on a test server.

I wonder what the record is for the most amount of bitcoind instances running together successfully... anyone running 3 or more?


how did you manage to do that?
can you give me the startup command line/config pls.
2112
Legendary
*
Offline Offline

Activity: 1708



View Profile
December 19, 2015, 12:13:02 AM
 #30

how did you manage to do that?
can you give me the startup command line/config pls.
This thread is only of historical relevance. It pertains to the old version that used BerkelyDB for everything. Current version uses a mixture of BerkeleyDB and LevelDB, so it doesn't apply.

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
Pages: « 1 [2]  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!