Multiple bitcoind on one machine | Bitcointalksearch.org

2112

legendary

Activity: 2128

Merit: 1073

Quote from: tolazy on December 18, 2015, 04:46:38 PM

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.

tolazy

full member

Activity: 196

Merit: 100

Quote from: payb.tc on August 06, 2011, 08:07:24 AM

Quote from: 2112 on August 05, 2011, 09:19:01 PM

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.

jfreak53

sr. member

Activity: 298

Merit: 252

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

2112

legendary

Activity: 2128

Merit: 1073

Quote from: jfreak53 on August 17, 2011, 09:05:02 PM

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.

jfreak53

sr. member

Activity: 298

Merit: 252

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?

2112

legendary

Activity: 2128

Merit: 1073

Quote from: jfreak53 on August 17, 2011, 10:35:55 AM

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.

jfreak53

sr. member

Activity: 298

Merit: 252

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.

payb.tc

hero member

Activity: 812

Merit: 1000

Quote from: c_k on August 08, 2011, 05:34:20 AM

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

[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.

payb.tc

hero member

Activity: 812

Merit: 1000

Quote from: c_k on August 08, 2011, 05:34:20 AM

Quote from: payb.tc on August 08, 2011, 05:15:30 AM

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

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?

wumpus

hero member

Activity: 812

Merit: 1022

No Maps for These Territories

Quote from: 2112 on August 06, 2011, 09:45:33 AM

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.

c_k

donator

Activity: 242

Merit: 100

Quote from: payb.tc on August 08, 2011, 05:15:30 AM

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

payb.tc

hero member

Activity: 812

Merit: 1000

Quote from: c_k on August 08, 2011, 05:02:39 AM

OP: what is wrong with the existing functionality of Accounts in wallets?

https://en.bitcoin.it/wiki/Accounts_explained

how about a lack of sub-accounts and sub-sub-accounts?

just one reason of many, i'd say.

c_k

donator

Activity: 242

Merit: 100

OP: what is wrong with the existing functionality of Accounts in wallets?

https://en.bitcoin.it/wiki/Accounts_explained

doldgigger

full member

Activity: 170

Merit: 100

Quote from: Furyan on August 06, 2011, 03:46:16 PM

I would think if the core devs were going to work against a goal, it would be mining pools. Mining pools were NEVER what Satoshi had in mind and de-democratize the mining process. They also concentrate computing power in attackable entities, and if a large pool goes down even for a few hours it takes a huge chunk of the available computing power with it (unless a large portion of the miners have fallback settings, but it doesn't appear to be widely used).

This is not the responsibility of the core devs, it is the responsibility of every bitcoin user. However, they are probably a natural effect of bitcoin's evolution - in other areas of P2P computing, you will also notice that evolution towards efficiency often leads to some kind of hub nodes. For bitcoin, I could imagine even more areas beyond mining where this might happen in the future.

But mining pools are not necessarily dangerous if we regulate them well. I have already started discussing about revitalizing the transaction fee market in presence of mining pools some time ago (see https://bitcointalksearch.org/topic/transaction-processing-policies-28309). I'd be glad to discuss further possibilities.

Steve

hero member

Activity: 868

Merit: 1008

Quote from: payb.tc on August 06, 2011, 08:07:24 AM

Quote from: 2112 on August 05, 2011, 09:19:01 PM

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?

I've run as many as 6 on a machine...two that are on a private local testnet...one that is on a prive testnet between several machines, one on the public test net and another couple on the real net. Works fine, albeit the machine can get a little sluggish. I do typically run 2 to 4 (2 on a private local testnet, one no a shared private testnet, and one on the real net).

error

hero member

Activity: 588

Merit: 500

Quote from: 2112 on August 06, 2011, 08:39:30 PM

Quote from: Furyan on August 06, 2011, 03:46:16 PM

They haven't done so. I tend to think the project is far beyond working against specific goals at this point and only working toward very focused ones.

Well, I probably cannot change your thinking. In my opinion the great part of the effective obfuscation is to appear constructive. I'll give you an example: Bitcoin protocol is a train-wreck of endianness and alignment problems. Yet while it was being developed some "core team" members were using MacOS X {Tiger,Leopard,Snow Leopard} which makes it almost trivial to locate and fix those problems.

Consider the code:

Code:

#include 
union {
        char b[4];
        int w;
} t = { 0x11, 0x22, 0x33, 0x44 };
int main()
{
        return printf("%08x,%i\n",t.w,(int)sizeof(void*));
}

and its compilation and invocation:

Code:

$ gcc -arch ppc -arch i386 -arch x86_64 bo.c
$ ./a.out
44332211,8
$ arch -i386 ./a.out
44332211,4
$ arch -ppc ./a.out
11223344,4

Now go search the history of this forum for discussion about the byte-order issues. Watch the mental gymnastics expended (especially by Jeff Garzik) to quash any work or discussion about this goal.

I'll bet this will be very instructive to you, even if you disagree with me overall.

Completely agree in every respect. The endianness problem is Bitcoin's biggest design flaw, and IMO warrants bumping the protocol version. Of course it's going to be a lot more work to clean this up than it would have been to do it right the first time, so it's going to be very hard to find anyone who wants to do it.

2112

legendary

Activity: 2128

Merit: 1073

Quote from: Furyan on August 06, 2011, 03:46:16 PM

They haven't done so. I tend to think the project is far beyond working against specific goals at this point and only working toward very focused ones.

Well, I probably cannot change your thinking. In my opinion the great part of the effective obfuscation is to appear constructive. I'll give you an example: Bitcoin protocol is a train-wreck of endianness and alignment problems. Yet while it was being developed some "core team" members were using MacOS X {Tiger,Leopard,Snow Leopard} which makes it almost trivial to locate and fix those problems.

Consider the code:

Code:

#include 
union {
        char b[4];
        int w;
} t = { 0x11, 0x22, 0x33, 0x44 };
int main()
{
        return printf("%08x,%i\n",t.w,(int)sizeof(void*));
}

and its compilation and invocation:

Code:

$ gcc -arch ppc -arch i386 -arch x86_64 bo.c
$ ./a.out
44332211,8
$ arch -i386 ./a.out
44332211,4
$ arch -ppc ./a.out
11223344,4

Now go search the history of this forum for discussion about the byte-order issues. Watch the mental gymnastics expended (especially by Jeff Garzik) to quash any work or discussion about this goal.

I'll bet this will be very instructive to you, even if you disagree with me overall.

payb.tc

hero member

Activity: 812

Merit: 1000

Quote from: 2112 on August 06, 2011, 05:22:26 PM

Quote from: payb.tc on August 06, 2011, 10:05:09 AM

which goal?

The goal of having multiple compatible implementations of the same protocol.

okay so you said all that because i used the phrase 'modify bitcoind'. i didn't mean fork the project, i meant it would be good if that functionality became part of the default client.

2112

legendary

Activity: 2128

Merit: 1073

Quote from: payb.tc on August 06, 2011, 10:05:09 AM

which goal?

The goal of having multiple compatible implementations of the same protocol. The longer they have an effective control over the whole network in the hands of about 6 people the more time they have to monetize their investment of time into this project.

It is quite amazing to watch an open source project that had successfully prevented any competing groups from developing a compatible implementation despite the source being in the open. Subtle changes in protocol, using corner cases of exception handling to prevent running the Linux client on the majority of commercial Linux distributions, reintroducing exact bugs fixed in earlier patches, etc. The whole arsenal of tricks of hardcore purveyors of job safety.

I have to say that watching this project is a great learning experience for me.

Furyan

full member

Activity: 175

Merit: 102

Quote from: payb.tc on August 06, 2011, 10:05:09 AM

Quote from: 2112 on August 06, 2011, 09:45:33 AM

Quote from: payb.tc on August 06, 2011, 09:06:05 AM

so i guess the solution is to modify bitcoind so that it can perform the functions of multiple bitcoind instances?
run several wallets at the same time, separately, all from the one binary and one set of ports.

I think I responded to you in the PHP thread. Your only hope is that libbitcoin development group delivers something useable. The core development team is actively working against this goal. What you have here is the essence of using obfuscated C++ code for the purpose of guerrilla warfare amongst the competing software development teams. Satoshi is/was a grand-master of it.

which goal? what's wrong with one instance of bitcoind managing multiple wallets?

I, too, am curious what motivated that comment.

I would think if the core devs were going to work against a goal, it would be mining pools. Mining pools were NEVER what Satoshi had in mind and de-democratize the mining process. They also concentrate computing power in attackable entities, and if a large pool goes down even for a few hours it takes a huge chunk of the available computing power with it (unless a large portion of the miners have fallback settings, but it doesn't appear to be widely used).

The GetWork function was intended for testing, but is the single method by which mining pools are even possible. If they wanted to work against a goal - mining pools - they'd need only to disable that single function.

They haven't done so. I tend to think the project is far beyond working against specific goals at this point and only working toward very focused ones.

Topic: Multiple bitcoind on one machine (Read 6096 times)