2024-06-05 15:08:29 +00:00
|
|
|
# Nimbus
|
|
|
|
# Copyright (c) 2024 Status Research & Development GmbH
|
|
|
|
# Licensed under either of
|
|
|
|
# * Apache License, version 2.0, ([LICENSE-APACHE](LICENSE-APACHE) or
|
|
|
|
# http://www.apache.org/licenses/LICENSE-2.0)
|
|
|
|
# * MIT license ([LICENSE-MIT](LICENSE-MIT) or
|
|
|
|
# http://opensource.org/licenses/MIT)
|
|
|
|
# at your option. This file may not be copied, modified, or distributed
|
|
|
|
# except according to those terms.
|
|
|
|
|
|
|
|
{.push raises: [].}
|
|
|
|
|
|
|
|
import results
|
|
|
|
|
|
|
|
export results
|
|
|
|
|
|
|
|
const
|
|
|
|
# https://github.com/facebook/rocksdb/wiki/Setup-Options-and-Basic-Tuning
|
Speed up initial MPT root computation after import (#2788)
When `nimbus import` runs, we end up with a database without MPT roots
leading to long startup times the first time one is needed.
Computing the state root is slow because the on-disk order based on
VertexID sorting does not match the trie traversal order and therefore
makes lookups inefficent.
Here we introduce a helper that speeds up this computation by traversing
the trie in on-disk order and computing the trie hashes bottom up
instead - even though this leads to some redundant reads of nodes that
we cannot yet compute, it's still a net win as leaves and "bottom"
branches make up the majority of the database.
This PR also addresses a few other sources of inefficiency largely due
to the separation of AriKey and AriVtx into their own column families.
Each column family is its own LSM tree that produces hundreds of SST
filtes - with a limit of 512 open files, rocksdb must keep closing and
opening files which leads to expensive metadata reads during random
access.
When rocksdb makes a lookup, it has to read several layers of files for
each lookup. Ribbon filters to skip over files that don't have the
requested data but when these filters are not in memory, reading them is
slow - this happens in two cases: when opening a file and when the
filter has been evicted from the LRU cache. Addressing the open file
limit solves one source of inefficiency, but we must also increase the
block cache size to deal with this problem.
* rocksdb.max_open_files increased to 2048
* per-file size limits increased so that fewer files are created
* WAL size increased to avoid partial flushes which lead to small files
* rocksdb block cache increased
All these increases of course lead to increased memory usage, but at
least performance is acceptable - in the future, we'll need to explore
options such as joining AriVtx and AriKey and/or reducing the row count
(by grouping branch layers under a single vertexid).
With this PR, the mainnet state root can be computed in ~8 hours (down
from 2-3 days) - not great, but still better.
Further, we write all keys to the database, also those that are less
than 32 bytes - because the mpt path is part of the input, it is very
rare that we actually hit a key like this (about 200k such entries on
mainnet), so the code complexity is not worth the benefit really, in the
current database layout / design.
2024-10-27 11:08:37 +00:00
|
|
|
defaultMaxOpenFiles* = 2048
|
2024-06-05 15:08:29 +00:00
|
|
|
defaultWriteBufferSize* = 64 * 1024 * 1024
|
2024-09-05 09:18:32 +00:00
|
|
|
defaultRowCacheSize* = 0
|
|
|
|
## The row cache is disabled by default as the rdb lru caches do a better
|
|
|
|
## job at a similar abstraction level - ie they work at the same granularity
|
|
|
|
## as the rocksdb row cache but with less overhead
|
Speed up initial MPT root computation after import (#2788)
When `nimbus import` runs, we end up with a database without MPT roots
leading to long startup times the first time one is needed.
Computing the state root is slow because the on-disk order based on
VertexID sorting does not match the trie traversal order and therefore
makes lookups inefficent.
Here we introduce a helper that speeds up this computation by traversing
the trie in on-disk order and computing the trie hashes bottom up
instead - even though this leads to some redundant reads of nodes that
we cannot yet compute, it's still a net win as leaves and "bottom"
branches make up the majority of the database.
This PR also addresses a few other sources of inefficiency largely due
to the separation of AriKey and AriVtx into their own column families.
Each column family is its own LSM tree that produces hundreds of SST
filtes - with a limit of 512 open files, rocksdb must keep closing and
opening files which leads to expensive metadata reads during random
access.
When rocksdb makes a lookup, it has to read several layers of files for
each lookup. Ribbon filters to skip over files that don't have the
requested data but when these filters are not in memory, reading them is
slow - this happens in two cases: when opening a file and when the
filter has been evicted from the LRU cache. Addressing the open file
limit solves one source of inefficiency, but we must also increase the
block cache size to deal with this problem.
* rocksdb.max_open_files increased to 2048
* per-file size limits increased so that fewer files are created
* WAL size increased to avoid partial flushes which lead to small files
* rocksdb block cache increased
All these increases of course lead to increased memory usage, but at
least performance is acceptable - in the future, we'll need to explore
options such as joining AriVtx and AriKey and/or reducing the row count
(by grouping branch layers under a single vertexid).
With this PR, the mainnet state root can be computed in ~8 hours (down
from 2-3 days) - not great, but still better.
Further, we write all keys to the database, also those that are less
than 32 bytes - because the mpt path is part of the input, it is very
rare that we actually hit a key like this (about 200k such entries on
mainnet), so the code complexity is not worth the benefit really, in the
current database layout / design.
2024-10-27 11:08:37 +00:00
|
|
|
defaultBlockCacheSize* = 4 * 1024 * 1024 * 1024
|
|
|
|
## The block cache is used to cache indicies, ribbon filters and
|
|
|
|
## decompressed data, roughly in that priority order. At the time of writing
|
|
|
|
## we have about 2 giga-entries in the MPT - with the ribbon filter
|
|
|
|
## using about 8 bits per entry we need 2gb of space just for the filters.
|
|
|
|
##
|
|
|
|
## When the filters don't fit in memory, random access patterns such as
|
|
|
|
## MPT root computations suffer because of filter evictions and subsequent
|
|
|
|
## re-reads from file.
|
|
|
|
##
|
|
|
|
## We have two "principal" tables, AriVtx and AriKey - since they live in
|
|
|
|
## separate column families, they have separate filters meaning that we need
|
|
|
|
## double the total index and ribbon filter size for good performance.
|
2024-09-05 09:18:32 +00:00
|
|
|
defaultRdbVtxCacheSize* = 512 * 1024 * 1024
|
|
|
|
## Cache of branches and leaves in the state MPTs (world and account)
|
|
|
|
defaultRdbKeyCacheSize* = 256 * 1024 * 1024
|
|
|
|
## Hashes of the above
|
|
|
|
|
2024-06-05 15:08:29 +00:00
|
|
|
|
|
|
|
type DbOptions* = object # Options that are transported to the database layer
|
|
|
|
maxOpenFiles*: int
|
|
|
|
writeBufferSize*: int
|
|
|
|
rowCacheSize*: int
|
|
|
|
blockCacheSize*: int
|
2024-09-05 09:18:32 +00:00
|
|
|
rdbVtxCacheSize*: int
|
|
|
|
rdbKeyCacheSize*: int
|
|
|
|
rdbPrintStats*: bool
|
2024-06-05 15:08:29 +00:00
|
|
|
|
|
|
|
func init*(
|
|
|
|
T: type DbOptions,
|
|
|
|
maxOpenFiles = defaultMaxOpenFiles,
|
|
|
|
writeBufferSize = defaultWriteBufferSize,
|
|
|
|
rowCacheSize = defaultRowCacheSize,
|
|
|
|
blockCacheSize = defaultBlockCacheSize,
|
2024-09-05 09:18:32 +00:00
|
|
|
rdbVtxCacheSize = defaultRdbVtxCacheSize,
|
|
|
|
rdbKeyCacheSize = defaultRdbKeyCacheSize,
|
|
|
|
rdbPrintStats = false,
|
2024-06-05 15:08:29 +00:00
|
|
|
): T =
|
|
|
|
T(
|
|
|
|
maxOpenFiles: maxOpenFiles,
|
|
|
|
writeBufferSize: writeBufferSize,
|
|
|
|
rowCacheSize: rowCacheSize,
|
|
|
|
blockCacheSize: blockCacheSize,
|
2024-09-05 09:18:32 +00:00
|
|
|
rdbVtxCacheSize: rdbVtxCacheSize,
|
|
|
|
rdbKeyCacheSize: rdbKeyCacheSize,
|
|
|
|
rdbPrintStats: rdbPrintStats,
|
2024-06-05 15:08:29 +00:00
|
|
|
)
|