#### Problem
The current implementation of get_slots_since() invokes multiple rocksdb::get().
As a result, each get() operation may end up requiring one disk read. This leads
to poor performance of get_slots_since described in #24878.
#### Summary of Changes
This PR makes get_slots_since() use the batched version of multi_get() instead,
which allows multiple get operations to be processed in batch so that they can
be answered with fewer disk reads.
This makes web3.js compatible with runtimes that don't understand bigint literals but _do_ understand `BigInt` constructors.
For whatever that's worth.
* Remove markdown file update from version increment-cargo-version.sh
* Update doc version numbers that were incorrectly advanced by increment-cargo-version.sh
* Revert incorrect doc change based on review feedback
Several of the get() methods return a deserialized object (as opposed to
a Vec<u8>) by first getting a byte array out of Rocks, and then using
bincode::deserialize() to get the underlying type. However,
deserialize() only requires a u8 slice, not an owned Vec<u8>. So, we can
use get_pinned_cf() to reference memory owned by Rocks and avoid an
unnecessary copy.
Setting pool idle timeout to a value smaller than solana-watchtower's
poll interval can fix following error:
[2022-08-25T04:03:22.811160892Z INFO solana_watchtower] Failure 1 of 3: solana-watchtower testnet: Error: rpc-error: error sending request for url (https://api.testnet.solana.com/): connection closed before message completed
It looks like this happens because either RPC servers or ISPs drop HTTP
connections without properly notifying the client in some cases.
Similar issue: https://github.com/hyperium/hyper/issues/2136.
This helps to distinguish between Mainnet and Testnet notifications sent
into the same notification channel. Usage example:
solana-watchtower --name-suffix " mainnet" ...
solana-watchtower --name-suffix " testnet" ...
#### Problem
Previously before #26651, our LedgerCleanupService needs RocksDB background
compactions to reclaim ledger disk space via our custom CompactionFilter.
However, since RocksDB's compaction isn't smart enough to know which file to pick,
we rely on the 1-day compaction period so that each file will be forced to be compacted
once a day so that we can reclaim ledger disk space in time. The downside of this is
each ledger file will be rewritten once per day.
#### Summary of Changes
As #26651 makes LedgerCleanupService actively delete those files whose entire slot-range
is older than both --limit-ledger-size and the current root, we can remove the 1-day compaction
period and get rid of the daily ledger file rewrite.
The results on mainnet-beta shows that this PR reduces ~20% write-bytes-per-second
and reduces ~50% read-bytes-per-second on ledger disk.