Fabric v1.4单Peer节点内存占用过高且交易完成后不自动释放问题咨询

1. 链码侧内存泄漏排查 #

• 先执行docker stats分别统计Peer容器和对应链码容器的内存变化，排除链码容器本身内存泄漏被误统计到Peer侧的问题。
• 检查链码是否存在全局变量持有1MB级别的交易输入数据未释放的逻辑，若使用Go语言开发链码，可给链码容器添加启动环境变量GODEBUG=gctrace=1，复现问题后查看GC日志，确认链码侧是否存在内存无法回收的情况；Node.js、Java链码同理开启GC日志排查即可。

2. Peer节点配置校验 #

• 检查core.yaml中ledger.state.stateDatabase配置，若使用CouchDB作为状态数据库，确认ledger.state.couchDBConfig.maxRetries、ledger.state.couchDBConfig.queryLimit参数未被配置为过大值，避免CouchDB客户端缓存大量未提交的冲突交易读写集无法释放。
• 单节点部署场景下直接将peer.gossip.enabled设为false，关闭不必要的Gossip协议通信，避免失效消息堆积占用内存。
• 临时关闭ledger.history.enableHistoryDatabase配置后复现问题，确认是否是大交易的历史数据缓存泄漏导致内存不回落。

3. 内存快照定位泄漏点 #

• 给Peer容器添加启动环境变量CORE_PEER_PROFILE_ENABLED=true，暴露pprof调试端口6060，复现交易流程后执行命令go tool pprof http://<Peer节点IP>:6060/debug/pprof/heap抓取堆内存快照。
• 分析内存快照中top20的内存占用对象，重点关注kvledger、rwsetutil相关的模块对象，Fabric v1.4早期小版本存在未提交冲突交易的读写集缓存未被GC回收的已知问题，若定位到该模块内存占比过高，可升级到v1.4.12（v1.4最终维护版本）修复，或手动移植对应补丁。

4. 临时规避方案 #

• 调低ledger.totalQueryLimit参数限制单次交易的读写集缓存上限，同时缩小peer.authentication.timewindow的配置值，让超时的交易处理上下文尽快被回收。
• 大交易场景下避免并行提交修改同一Key的交易，减少MVCC冲突产生的无效读写集堆积。

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