2112 (OP)
Legendary
Offline
Activity: 2128
Merit: 1073
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 12, 2013, 10:08:16 AM Last edit: March 12, 2013, 04:07:36 PM by 2112 |
|
Just create the file named "DB_CONFIG" in the ".bitcoin" or "AppData/Roaming/Bitcoin" directory that contains the following: 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.
|
|
|
|
bitcoinBull
Legendary
Offline
Activity: 826
Merit: 1001
rippleFanatic
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 12, 2013, 05:44:47 PM |
|
This why any settings should always be set explicitly, even if they have defaults. It makes it harder to forget about them.
|
College of Bucking Bulls Knowledge
|
|
|
paraipan
In memoriam
Legendary
Offline
Activity: 924
Merit: 1004
Firstbits: 1pirata
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 12, 2013, 06:52:50 PM |
|
...
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.
|
BTCitcoin: An Idea Worth Saving - Q&A with bitcoins on rugatu.com - Check my rep
|
|
|
marcus_of_augustus
Legendary
Offline
Activity: 3920
Merit: 2349
Eadem mutata resurgo
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 12, 2013, 06:57:04 PM |
|
...
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
In memoriam
Legendary
Offline
Activity: 924
Merit: 1004
Firstbits: 1pirata
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 12, 2013, 06:59:36 PM |
|
...
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.
|
BTCitcoin: An Idea Worth Saving - Q&A with bitcoins on rugatu.com - Check my rep
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4228
Merit: 8644
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 12, 2013, 07:46:14 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.
|
|
|
|
marcus_of_augustus
Legendary
Offline
Activity: 3920
Merit: 2349
Eadem mutata resurgo
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 12, 2013, 08: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.htmlThe 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.
|
|
|
|
paraipan
In memoriam
Legendary
Offline
Activity: 924
Merit: 1004
Firstbits: 1pirata
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 12, 2013, 08:43:45 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.htmlThe 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.
|
BTCitcoin: An Idea Worth Saving - Q&A with bitcoins on rugatu.com - Check my rep
|
|
|
bitcoinBull
Legendary
Offline
Activity: 826
Merit: 1001
rippleFanatic
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 12, 2013, 09:14:38 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.
|
College of Bucking Bulls Knowledge
|
|
|
paraipan
In memoriam
Legendary
Offline
Activity: 924
Merit: 1004
Firstbits: 1pirata
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 12, 2013, 10:43:30 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
|
BTCitcoin: An Idea Worth Saving - Q&A with bitcoins on rugatu.com - Check my rep
|
|
|
marcus_of_augustus
Legendary
Offline
Activity: 3920
Merit: 2349
Eadem mutata resurgo
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 13, 2013, 02:30:58 AM |
|
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.
|
|
|
|
|