Is there an existing issue?
Experiencing problems? Have you tried our Stack Exchange first?
Request
The statement store maintains an in-memory expired:
|
expired: HashMap<Hash, u64>, // Value is expiration timestamp. |
that tracks hashes of removed/evicted statements to prevent peers from re-gossiping them.
- Unbounded growth, unlike
entries (capped at 4M statements / 2GiB), the expired map has no capacity limit
- Inefficient purge
|
self.expired.retain(|hash, timestamp| { |
During high-throughput scenarios the expired map grows to ~100M entries, consuming an estimated ~9GB of RAM (100M entries × 104 bytes: 32-byte hash + 8-byte timestamp + ~64 bytes HashMap overhead)
Solution
Replace the flat HashMap<Hash, u64> with a time-bucketed ExpiredIndex:
struct ExpiredIndex {
/// O(1) dedup lookup (hash -> bucket_id)
lookup: HashMap<Hash, u64>,
/// Time buckets ordered by age (bucket_id -> set of hashes)
buckets: BTreeMap<u64, HashSet<Hash>>,
}
Are you willing to help with this request?
Yes!
Is there an existing issue?
Experiencing problems? Have you tried our Stack Exchange first?
Request
The statement store maintains an in-memory expired:
polkadot-sdk/substrate/client/statement-store/src/lib.rs
Line 235 in ae772b4
entries(capped at 4M statements / 2GiB), the expired map has no capacity limitpolkadot-sdk/substrate/client/statement-store/src/lib.rs
Line 456 in ae772b4
During high-throughput scenarios the expired map grows to ~100M entries, consuming an estimated ~9GB of RAM (100M entries × 104 bytes: 32-byte hash + 8-byte timestamp + ~64 bytes HashMap overhead)
Solution
Replace the flat HashMap<Hash, u64> with a time-bucketed ExpiredIndex:
Are you willing to help with this request?
Yes!