Aleksandr Logunov

Compaction stats length is limited to 65536

2

### Expected behavior Get full compaction logs after calling `DBImpl::DumpStats`: https://github.com/facebook/rocksdb/blob/9ef7f70c11e26ac82bc3716d47902ad3a773fa48/db/db_impl/db_impl.cc#L893 ### Actual behavior Instead, compaction stats length is limited to 65536, which results in only partial logs display (in...

Add BorshSize trait

3

Discussion started here: https://github.com/near/nearcore/pull/4107#discussion_r594754389 The point is to wrap object' serialization and length computation in one method. CC: @nearmax

Improve shard cache to use RAM more effectively. Three changes are introduced: 1) If we put new value to LRU cache and total size of existing values exceeds `total_sizes_capacity`, we...

We use tracing for collecting shard/chunk cache hits, but we want to be able to export such data to prometheus as well. Metrics ideas could be taken from [https://github.com/Longarithm/nearcore/compare/master...smart-cache](https://github.com/Longarithm/nearcore/compare/master...smart-cache "smart-link")...

We update shard cache based on `TrieChanges.insertions` and `deletions` field, and they come a long way to it: * they are converted to DB transaction ops * then DB transaction...

test_block_sync is flaky

3

If I run this test multiple times, result may be either pass or fail: https://near.zulipchat.com/#narrow/stream/295558-pagoda.2Fcore/topic/test_block_sync.20flaky.3F/near/292419577 Buildkite example https://buildkite.com/nearprotocol/nearcore/builds/18839#0182832c-ef40-4dca-a31c-040429f68b05 cc @mzhangmzz

There is a `tries.update_cache` method get called on `StoreUpdate::commit` which puts fresh nodes to the shard cache. However, it is not called in state-viewer, which may show worse performance in...

This is a simple flat storage migration for localnet. It iterates over all nodes sequentially, which is viable for small states but doesn't work for testnet/mainnet. ``` # Build and...

DBCol::StateChanges basically maps TrieKeys to values. However, the same values are stored in DBCol::State, keyed by hash, and have the same liveness time. So we could dramatically optimise disk space...