Substrate状态缓存达20MB后性能下降相关问题咨询

问题1：该现象的成因是什么？为什么5次完全相同的测试无法得到一致结果？ #

Substrate 状态缓存默认采用 LRU（最近最少使用）淘汰策略，首次测试时缓存为空，新写入的状态数据可直接存入缓存，无额外淘汰开销，因此性能最稳定。当缓存占用达到阈值（当前场景下为20MB）时，每写入一个新的状态条目，就需要先淘汰最少使用的旧条目，额外产生的CPU、内存开销会直接拉高资源占用，同时未命中缓存的状态请求需要直接读取磁盘RocksDB，IO开销骤增，最终导致交易完成率下降。
5次测试结果不一致是因为前序测试的残留状态数据会留在缓存中，每次测试启动时缓存内的冷热数据分布、淘汰频率都存在差异，叠加验证人节点出块开销、交易池排序波动、自定义Pallet状态读写频率的微小波动，最终呈现出结果不稳定的情况。

问题2：状态缓存和节点性能之间是否存在关联？ #

二者存在直接关联：

• 缓存未占满且命中率高时，常用状态数据直接从内存读取，无需访问磁盘，状态读写效率可提升数倍，节点TPS、交易完成率都能维持在较高水平；
• 缓存占满触发淘汰后，缓存命中率下降，频繁的磁盘IO和缓存淘汰开销会直接拉低节点处理性能，交易排队、超时丢弃的概率大幅升高，交易完成率自然下降。

问题3：增大--state-cache-size参数是否可以提升性能？ #

当前场景下调整该参数可以明确提升性能。你当前的性能瓶颈就是默认状态缓存阈值过低，提前触发了频繁的缓存淘汰和磁盘IO，只要节点内存充足，将--state-cache-size调整到128MB或256MB即可（建议不要超过节点可用内存的1/4，预留足够内存给Wasm执行、交易池、网络模块使用），可避免频繁淘汰的问题，缓存命中率提升后，交易完成率会回到首次测试的稳定水平。
注意不要过度调大该参数，避免占用过多内存影响其他模块运行，反而引发性能下降。

节点启动命令调整参考 #

你可在原有启动命令中新增--state-cache-size参数即可调整缓存大小，示例如下：

node-template \
--base-path /datas/substrate-0 \
--name Node0 \
--chain /genesis/customSpecRaw.json \
--port 30333 \
--ws-port 9944 \
--rpc-port 9933 \
--node-key 0000000000000000000000000000000000000000000000000000000000000001 \
--unsafe-ws-external \
--unsafe-rpc-external \
--rpc-cors=all \
--prometheus-external \
--log info \
--wasm-execution Compiled \
--ws-max-connections 1000 \
--pool-limit 10000 \
--pool-kbytes 20480 \
--validator \
--max-runtime-instances 100 \
--state-cache-size 134217728

上述示例中134217728为128MB对应的字节数，可根据实际内存情况调整。

内容的提问来源于stack exchange，提问作者lucgerrits