Whatever you do, just leave the "set_lg_dir database" line in the DB_CONFIG file. Otherwise you will not be able to use "db_stat" and other Berkeley DB utilities to debug the problems in the future. And then you will be back to being like the Bitcoin core development group: debugging blindly at the lowest level and trying to run the utils will corrupt the DB environment because log files were inaccessible.
Or man up and move the log files up one level from the "database" directory. Then the utilities will work correctly without the configuration file.
Have fun.
Topic: The Uncommanded Fork Problem (Read 765 times)
It appears this problem depends on the size of transaction index.
Thanks Mark for the pointer.
Thanks Mark for the pointer.
Quote
The maximum number of lock objects needed can be estimated as follows:
For Btree and Recno access methods, you will need one lock object per level of the database tree, at a minimum. (Unless keys are quite large with respect to the page size, neither Recno nor Btree database trees should ever be deeper than five levels.) Then, you will need one lock object for each leaf page of the database tree that will be simultaneously accessed.
For the Queue access method, you will need one lock object per record that is simultaneously accessed. To this, add one lock object per page that will be simultaneously accessed. (Because the Queue access method uses fixed-length records and the database page size is known, it is possible to calculate the number of pages -- and, therefore, the lock objects -- required.) Deleted records skipped by a DB_NEXT or DB_PREV operation do not require a separate lock object. Further, if your application is using transactions, no database operation will ever use more than three lock objects at any time.
For the Hash access method, you only need a single lock object.
For all access methods, you should then add an additional lock object per database for the database's metadata page.
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.
For Btree and Recno access methods, you will need one lock object per level of the database tree, at a minimum. (Unless keys are quite large with respect to the page size, neither Recno nor Btree database trees should ever be deeper than five levels.) Then, you will need one lock object for each leaf page of the database tree that will be simultaneously accessed.
For the Queue access method, you will need one lock object per record that is simultaneously accessed. To this, add one lock object per page that will be simultaneously accessed. (Because the Queue access method uses fixed-length records and the database page size is known, it is possible to calculate the number of pages -- and, therefore, the lock objects -- required.) Deleted records skipped by a DB_NEXT or DB_PREV operation do not require a separate lock object. Further, if your application is using transactions, no database operation will ever use more than three lock objects at any time.
For the Hash access method, you only need a single lock object.
For all access methods, you should then add an additional lock object per database for the database's metadata page.
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.
Look in db.cpp
There are three settings related to locks, see
http://www.stanford.edu/class/cs276a/projects/docs/berkeleydb/ref/lock/max.html
If increasing one of them to 40,000 from 10,000 is it really okay to leave the other two unchanged?
-MarkM-
There are three settings related to locks, see
http://www.stanford.edu/class/cs276a/projects/docs/berkeleydb/ref/lock/max.html
If increasing one of them to 40,000 from 10,000 is it really okay to leave the other two unchanged?
-MarkM-
Thanks for the tips, although this is probably not enough as it may cause chain fork again unless all nodes take the workaround?
Just create the file named "DB_CONFIG" in the ".bitcoin" or "AppData/Roaming/Bitcoin" directory that contains the following:
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.
Code:
set_lg_dir database
set_lk_max_locks 40000
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.
Stay tuned as I don't exclude the possibility of emergency patches for miners if there is immediate threat on block chain.
Chillax, dude. Your emergency patch is already available:Just create the file named "DB_CONFIG" in the ".bitcoin" or "AppData/Roaming/Bitcoin" directory that contains the following:
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.
Code:
set_lg_dir database
set_lk_max_locks 40000
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.
Most of you have probably heard about the shenanigans in the Bitcoin block chain recently, where an incompatibility in client versions briefly forced an uncommanded fork in the block chain. The situation seems contained, but questions remain. Since most of the alts use a very similar block chain, and their clients are near copies of Bitcoin's, how vulnerable are they to this same problem, and what could realistically be done about it?
I am following the bitcoin issue since yesterday it looks like the problem is with pre 0.8 clients that uses berkeley db. I think almost all altcoins are still based on bitcoin 0.7 or earlier, except for terracoin, so yes we are probably affected. I am monitoring the situation closely right now and will give updates as I get a better handle of the problem. Stay tuned as I don't exclude the possibility of emergency patches for miners if there is immediate threat on block chain.
Most of you have probably heard about the shenanigans in the Bitcoin block chain recently, where an incompatibility in client versions briefly forced an uncommanded fork in the block chain. The situation seems contained, but questions remain. Since most of the alts use a very similar block chain, and their clients are near copies of Bitcoin's, how vulnerable are they to this same problem, and what could realistically be done about it?
Jump to: