Commit Graph

33 Commits

Author SHA1 Message Date
Howard Chu edfd7f6e07
Workaround VL32 cursor refcounting miscount
Don't try to deref cursor page if txn's pagelist is empty
2017-01-31 10:38:12 +00:00
MoroccanMalinois 80abc3bc4a Build wallet with Android NDK 2017-01-05 01:11:05 +00:00
redfish e1c7af35d4 cmake: transitive deps and remove deprecated LINK_*
Keep the immediate direct deps at the library that depends on them,
declare deps as PUBLIC so that targets that link against that library
get the library's deps as transitive deps.

Break dep cycle between blockchain_db <-> crytonote_core.
No code refactoring, just hide cycle from cmake so that
it doesn't complain (cycles are allowed only between
static libs, not shared libs).

This is in preparation for supproting BUILD_SHARED_LIBS cmake
built-in option for building internal libs as shared.
2016-09-18 02:56:26 -04:00
Howard Chu 7442dd084a More for Issue #855
Plug rpage leak in cursor_set
2016-08-11 21:04:36 +01:00
Howard Chu d6f5d543a5 Fix Issue #855
Use the same size dirty list for both 64 and 32 bit.
2016-06-07 23:38:47 +01:00
Howard Chu 66b1e13aa7 mdb_drop optimization
If we know there are no sub-DBs and no overflow pages, skip leaf scan.
2016-04-09 20:44:05 +01:00
Howard Chu 6225716f3c More outputs consolidation
Also bumped DB VERSION to 1
Another significant speedup and space savings:
Get rid of global_output_indices, remove indirection from output to keys

This is the change warptangent described on irc but never got to finish.
2016-04-05 20:55:12 +01:00
Howard Chu 8860b7497f MDB_VL32 - increase max write txn size 2016-02-17 20:41:34 +00:00
Howard Chu 31e4e8c3a3 Resync with master 2016-02-16 23:38:04 +00:00
Howard Chu f98fe467e9 MDB_VL32 change overflow page scan
Just check the requested page, don't worry about any other pages
2016-01-28 13:59:02 +00:00
Howard Chu 7e65cc0aba MDB_VL32 Fix off-by-one in mdb_midl_shrink 2016-01-28 04:15:45 +00:00
Howard Chu 222e30ec97 MDB_VL32 Fix another 32bit overflow 2016-01-27 14:14:27 +00:00
Howard Chu 3ca6e853f6 Tweak mdb_strerror msg buffer 2016-01-27 14:14:11 +00:00
Howard Chu 78ad970a2c MDB_VL32 Fix d2a5f72f73
VirtualAlloc is not for MDB_VL32
2016-01-27 14:14:02 +00:00
Howard Chu 1cff3974d8 WIN64 needs off_t redefined too 2016-01-20 01:26:26 +00:00
Howard Chu d2a5f72f73 Fix --db-sync-mode on Windows64
only "fastest" mode was working, others would SEGV.
2016-01-16 16:11:11 +00:00
Riccardo Spagni de03926850
updated copyright year 2015-12-31 08:39:56 +02:00
Howard Chu b773e66877 MDB_VL32 - resync with master
WIN32 - close file mapping handle in env_close
cursor_unref - ignore cursor with empty stack
2015-12-28 20:46:48 +00:00
Howard Chu ba4e217c90 Update liblmdb, unify 32/64 sources 2015-12-25 08:56:03 +00:00
Riccardo Spagni 35b62fbd8e
hyc accidentally typo'd...we shall never speak of this again 2015-07-16 13:32:20 +02:00
Riccardo Spagni a4254a48f1
updated vl32 to current 2015-07-16 12:46:15 +02:00
Riccardo Spagni e6ab2dfdf3
updated in-source lmdb 2015-07-16 11:33:10 +02:00
Thomas Winget ea08c768e2 open() flag O_DSYNC isn't on BSD, use O_SYNC
If the detected OS is FreeBSD, tell LMDB to compile with
MDB_DSYNC=O_SYNC instead of the default O_DSYNC, as BSD does not
implement this flag.
2015-07-16 11:22:39 +02:00
NoodleDoodleNoodleDoodleNoodleDoodleNoo e5d2680094 ** CHANGES ARE EXPERIMENTAL (FOR TESTING ONLY)
Bockchain:
1. Optim: Multi-thread long-hash computation when encountering groups of blocks.
2. Optim: Cache verified txs and return result from cache instead of re-checking whenever possible.
3. Optim: Preload output-keys when encoutering groups of blocks. Sort by amount and global-index before bulk querying database and multi-thread when possible.
4. Optim: Disable double spend check on block verification, double spend is already detected when trying to add blocks.
5. Optim: Multi-thread signature computation whenever possible.
6. Patch: Disable locking (recursive mutex) on called functions from check_tx_inputs which causes slowdowns (only seems to happen on ubuntu/VMs??? Reason: TBD)
7. Optim: Removed looped full-tx hash computation when retrieving transactions from pool (???).
8. Optim: Cache difficulty/timestamps (735 blocks) for next-difficulty calculations so that only 2 db reads per new block is needed when a new block arrives (instead of 1470 reads).

Berkeley-DB:
1. Fix: 32-bit data errors causing wrong output global indices and failure to send blocks to peers (etc).
2. Fix: Unable to pop blocks on reorganize due to transaction errors.
3. Patch: Large number of transaction aborts when running multi-threaded bulk queries.
4. Patch: Insufficient locks error when running full sync.
5. Patch: Incorrect db stats when returning from an immediate exit from "pop block" operation.
6. Optim: Add bulk queries to get output global indices.
7. Optim: Modified output_keys table to store public_key+unlock_time+height for single transaction lookup (vs 3)
8. Optim: Used output_keys table retrieve public_keys instead of going through output_amounts->output_txs+output_indices->txs->output:public_key
9. Optim: Added thread-safe buffers used when multi-threading bulk queries.
10. Optim: Added support for nosync/write_nosync options for improved performance (*see --db-sync-mode option for details)
11. Mod: Added checkpoint thread and auto-remove-logs option.
12. *Now usable on 32-bit systems like RPI2.

LMDB:
1. Optim: Added custom comparison for 256-bit key tables (minor speed-up, TBD: get actual effect)
2. Optim: Modified output_keys table to store public_key+unlock_time+height for single transaction lookup (vs 3)
3. Optim: Used output_keys table retrieve public_keys instead of going through output_amounts->output_txs+output_indices->txs->output:public_key
4. Optim: Added support for sync/writemap options for improved performance (*see --db-sync-mode option for details)
5. Mod: Auto resize to +1GB instead of multiplier x1.5

ETC:
1. Minor optimizations for slow-hash for ARM (RPI2). Incomplete.
2. Fix: 32-bit saturation bug when computing next difficulty on large blocks.

[PENDING ISSUES]
1. Berkely db has a very slow "pop-block" operation. This is very noticeable on the RPI2 as it sometimes takes > 10 MINUTES to pop a block during reorganization.
   This does not happen very often however, most reorgs seem to take a few seconds but it possibly depends on the number of outputs present. TBD.
2. Berkeley db, possible bug "unable to allocate memory". TBD.

[NEW OPTIONS] (*Currently all enabled for testing purposes)
1. --fast-block-sync arg=[0:1] (default: 1)
	a. 0 = Compute long hash per block (may take a while depending on CPU)
	b. 1 = Skip long-hash and verify blocks based on embedded known good block hashes (faster, minimal CPU dependence)
2. --db-sync-mode arg=[[safe|fast|fastest]:[sync|async]:[nblocks_per_sync]] (default: fastest:async:1000)
	a. safe = fdatasync/fsync (or equivalent) per stored block. Very slow, but safest option to protect against power-out/crash conditions.
	b. fast/fastest = Enables asynchronous fdatasync/fsync (or equivalent). Useful for battery operated devices or STABLE systems with UPS and/or systems with battery backed write cache/solid state cache.
	Fast    - Write meta-data but defer data flush.
	Fastest - Defer meta-data and data flush.
	Sync    - Flush data after nblocks_per_sync and wait.
	Async   - Flush data after nblocks_per_sync but do not wait for the operation to finish.
3. --prep-blocks-threads arg=[n] (default: 4 or system max threads, whichever is lower)
        Max number of threads to use when computing long-hash in groups.
4. --show-time-stats arg=[0:1] (default: 1)
	Show benchmark related time stats.
5. --db-auto-remove-logs arg=[0:1] (default: 1)
	For berkeley-db only. Auto remove logs if enabled.

**Note: lmdb and berkeley-db have changes to the tables and are not compatible with official git head version.
	At the moment, you need a full resync to use this optimized version.

[PERFORMANCE COMPARISON]
**Some figures are approximations only.
Using a baseline machine of an i7-2600K+SSD+(with full pow computation):
1. The optimized lmdb/blockhain core can process blocks up to 585K for ~1.25 hours + download time, so it usually takes 2.5 hours to sync the full chain.
2. The current head with memory can process blocks up to 585K for ~4.2 hours + download time, so it usually takes 5.5 hours to sync the full chain.
3. The current head with lmdb can process blocks up to 585K for ~32 hours + download time and usually takes 36 hours to sync the full chain.

Averate procesing times (with full pow computation):
lmdb-optimized:
1. tx_ave = 2.5 ms / tx
2. block_ave = 5.87 ms / block
memory-official-repo:
1. tx_ave = 8.85 ms / tx
2. block_ave = 19.68 ms / block
lmdb-official-repo (0f4a036437)
1. tx_ave = 47.8 ms / tx
2. block_ave = 64.2 ms / block

**Note: The following data denotes processing times only (does not include p2p download time)
lmdb-optimized processing times (with full pow computation):
1. Desktop,  Quad-core / 8-threads 2600k  (8Mb) - 1.25 hours processing time (--db-sync-mode=fastest:async:1000).
2. Laptop,   Dual-core / 4-threads U4200  (3Mb) - 4.90 hours processing time (--db-sync-mode=fastest:async:1000).
3. Embedded, Quad-core / 4-threads Z3735F (2x1Mb) - 12.0 hours processing time (--db-sync-mode=fastest:async:1000).

lmdb-optimized processing times (with per-block-checkpoint)
1. Desktop,  Quad-core / 8-threads 2600k  (8Mb) - 10 minutes processing time (--db-sync-mode=fastest:async:1000).

berkeley-db optimized processing times (with full pow computation)
1. Desktop, Quad-core / 8-threads 2600k  (8Mb) - 1.8 hours processing time (--db-sync-mode=fastest:async:1000).
2. RPI2. Improved from estimated 3 months(???) into 2.5 days (*Need 2AMP supply + Clock:1Ghz + [usb+ssd] to achieve this speed) (--db-sync-mode=fastest:async:1000).

berkeley-db optimized processing times (with per-block-checkpoint)
1. RPI2. 12-15 hours (*Need 2AMP supply + Clock:1Ghz + [usb+ssd] to achieve this speed) (--db-sync-mode=fastest:async:1000).
2015-07-15 23:20:16 -07:00
Thomas Winget bed2331904
Require BerkeleyDB to be installed (for now) if building non-static 2015-04-22 01:51:14 -04:00
Riccardo Spagni 41f0a8fe4d
update lmdb64 2015-04-14 21:07:39 +02:00
Thomas Winget 9519526224
Only compile BerkeleyDB as an option in non-static 2015-04-07 15:02:20 -04:00
Thomas Winget 8e3347f310
Pull blockchain changes into berkeleydb branch 2015-03-17 19:52:53 -04:00
Thomas Winget 6e9e8ab620
Move db_drivers/ to external/
Also change LMDB Cmake variables to CACHE rather than upgrading them
through several parent scopes.
2015-03-17 18:55:24 -04:00
Thomas Winget 11e815761f
Revert "Moved db_drivers/ into external/ for consistency"
This reverts commit b21335642e.
2015-03-17 18:03:11 -04:00
Thomas Winget 43477b7dac
BerkeleyDB Blockchain building, not working yet
Everything except actually *using* BlockchainBDB is wired up, but the db
itself is not yet working.  Some error about user mem not large enough.
I think I know what this error means, but I can't determine the cause.

Notes: BerkeleyDB does not allow 0-indexing in its recno type databases,
  so block numbers *in the database* will be 1-indexed.  Modifications
  to indexing have been made as needed.
2015-03-16 09:14:51 -04:00
Thomas Winget cade0da8f1
CMake wiring, minor cleanup, minor test addition
Make Cmake things aware of BerkeleyDB and BlockchainBDB

Make the BlockchainDB unit tests aware of BlockchainBDB
2015-03-16 04:17:53 -04:00
Thomas Winget b21335642e
Moved db_drivers/ into external/ for consistency 2015-03-09 15:48:46 -04:00