No-recompilation fix for the "Lock table is out of available lock entries"

marcus_of_augustus

legendary

Activity: 3920

Merit: 2349

Eadem mutata resurgo

Quote from: paraipan on March 12, 2013, 05:43:30 PM

Quote from: bitcoinBull on March 12, 2013, 04:14:38 PM

Quote from: paraipan on March 12, 2013, 03:43:45 PM

Lol ^ they said the same thing about IPv4 when it was invented, who would need more than 4,294,967,296 IP addresses? Time for "Bitcoin-IPv6" databases, which 0.8 already uses.

In 0.8 BerkeleyDB was replaced with LevelDB.

^ exactly my point

but levelDB implementation didn't faithfully reproduce BDB behaviour, which is what it was minimally asked to do ... and that is what caused the fork.

0.7 and BDB is still king ... for now, for better or worse, for richer or poorer, etc ... bitcoiners are wedded to it.

paraipan

legendary

Activity: 924

Merit: 1004

Firstbits: 1pirata

Quote from: bitcoinBull on March 12, 2013, 04:14:38 PM

Quote from: paraipan on March 12, 2013, 03:43:45 PM

Lol ^ they said the same thing about IPv4 when it was invented, who would need more than 4,294,967,296 IP addresses? Time for "Bitcoin-IPv6" databases, which 0.8 already uses.

In 0.8 BerkeleyDB was replaced with LevelDB.

^ exactly my point

bitcoinBull

legendary

Activity: 826

Merit: 1001

rippleFanatic

Quote from: paraipan on March 12, 2013, 03:43:45 PM

Lol ^ they said the same thing about IPv4 when it was invented, who would need more than 4,294,967,296 IP addresses? Time for "Bitcoin-IPv6" databases, which 0.8 already uses.

In 0.8 BerkeleyDB was replaced with LevelDB.

paraipan

legendary

Activity: 924

Merit: 1004

Firstbits: 1pirata

Quote from: marcus_of_augustus on March 12, 2013, 03:23:19 PM

Here's the Berkeley DB tutorial for anyone who might want to do some reading on sizing your database correctly and lock limits.

http://www.stanford.edu/class/cs276a/projects/docs/berkeleydb/ref/lock/max.html

Quote

The maximum number of locks required by an application cannot be easily estimated. It is possible to calculate a maximum number of locks by multiplying the maximum number of lockers, times the maximum number of lock objects, times two (two for the two possible lock modes for each object, read and write). However, this is a pessimal value, and real applications are unlikely to actually need that many locks. Reviewing the Lock subsystem statistics is the best way to determine this value.

Lol ^ they said the same thing about IPv4 when it was invented, who would need more than 4,294,967,296 IP addresses? Time for "Bitcoin-IPv6" databases, which 0.8 already uses.

marcus_of_augustus

legendary

Activity: 3920

Merit: 2349

Eadem mutata resurgo

Here's the Berkeley DB tutorial for anyone who might want to do some reading on sizing your database correctly and lock limits.

http://www.stanford.edu/class/cs276a/projects/docs/berkeleydb/ref/lock/max.html

Quote

The maximum number of locks required by an application cannot be easily estimated. It is possible to calculate a maximum number of locks by multiplying the maximum number of lockers, times the maximum number of lock objects, times two (two for the two possible lock modes for each object, read and write). However, this is a pessimal value, and real applications are unlikely to actually need that many locks. Reviewing the Lock subsystem statistics is the best way to determine this value.

gmaxwell

staff

Activity: 4284

Merit: 8808

Quote from: marcus_of_augustus on March 12, 2013, 01:57:04 PM

Don't you think it is about time the "majority" decided what is best for the blockchain?
The reference implementation allows it. Upgrading via a hard fork is not the answer. The block limit needs to be decided by a consensus of the mining power and it is high time this issue was sorted out ... unless SatoshiDICE wants to do the right thing.

You're confusing two things. Pool operators and solo miners are only a _tiny_ subset of the users of the system, ones whos motivations are not always well aligned with everyone elses and are often only aligned by all the things they cannot control. For example, if it were really just up to miners— 50 BTC _forever_. But fortunately no one elses nodes would accept their inflationary blocks. Amusingly, turning things over to a majority of core developers would make it depend on more people than a majority of hashpower (which is very close to being decided by a single person right now); not that either is remotely acceptable.

Bitcoin is a participatory system which ought to respect the right of self determinism of all of its users.

paraipan

legendary

Activity: 924

Merit: 1004

Firstbits: 1pirata

Quote from: marcus_of_augustus on March 12, 2013, 01:57:04 PM

Quote from: paraipan on March 12, 2013, 01:52:50 PM

Quote from: 2112 on March 12, 2013, 05:08:16 AM

...

Please don't!

You will only make the things worse. Changing this setting is useless if the majority doesn't apply it, and you can even end up on a blockchain fork by yourself.

Don't you think it is about time the "majority" decided what is best for the blockchain?

The reference implementation allows it. Upgrading via a hard fork is not the answer. The block limit needs to be decided by a consensus of the mining power and it is high time this issue was sorted out ... unless SatoshiDICE wants to do the right thing.

Meh, I'm always with the majority like everyone else around these parts. Only thing is modifying such setting would get individuals prone to attack because miner majority will be still on 0.7 blockchain and software limitations. Only informing here, don't take it with me.

marcus_of_augustus

legendary

Activity: 3920

Merit: 2349

Eadem mutata resurgo

Quote from: paraipan on March 12, 2013, 01:52:50 PM

Quote from: 2112 on March 12, 2013, 05:08:16 AM

...

Please don't!

You will only make the things worse. Changing this setting is useless if the majority doesn't apply it, and you can even end up on a blockchain fork by yourself.

Don't you think it is about time the "majority" decided what is best for the blockchain?

The reference implementation allows it. Upgrading via a hard fork is not the answer. The block limit needs to be decided by a consensus of the mining power and it is high time this issue was sorted out ... unless SatoshiDICE wants to do the right thing.

paraipan

legendary

Activity: 924

Merit: 1004

Firstbits: 1pirata

Quote from: 2112 on March 12, 2013, 05:08:16 AM

...

Please don't!

You will only make the things worse. Changing this setting is useless if the majority doesn't apply it, and you can even end up on a blockchain fork by yourself.

bitcoinBull

legendary

Activity: 826

Merit: 1001

rippleFanatic

This why any settings should always be set explicitly, even if they have defaults. It makes it harder to forget about them.

2112

legendary

Activity: 2128

Merit: 1073

Just create the file named "DB_CONFIG" in the ".bitcoin" or "AppData/Roaming/Bitcoin" directory that contains the following:

Code:

set_lg_dir database
set_lk_max_locks 40000

The default was 10000. You can monitor the lock usage using "db_stat -e". I've tested it on an old laptop with 0.3.24 and 0.5.0. Obviously it will work with alt-coins based on the Bitcoin & BDB code. The same file should go into the respective "testnet" subdirectories.

Please don't omit the "set_lg_dir database" line. Without it you may corrupt the "_db.00?" and/or "log.*" files if you are unlucky and run the Berkeley DB utilities like "db_stat". With this line you will at worst get the error message from those utilities.

Good luck.

Edit: Oh, I forgot about the most obvious or non-obvious: restart the bitcoind/bitcoin-qt.

Topic: No-recompilation fix for the "Lock table is out of available lock entries" (Read 7339 times)