datanode疑似内存泄漏，v2.4.17版本，想咨询一下是否有已知的内存问题。

[qiqiqi998]

运行期间，只会周期性的对每个集合进行数据写入，查询和删除，期间数据总量不变。

写入操作如下：
针对20个集合中的10个分区以并发20，每个30分钟执行插入、查询、删除5000条数据的操作。并对数据做校验。

如下是运行4天的datanode的内存情况：

[xiaofan-luan]

可能不是泄漏，只是delete， bloomfilter的数目增多了。
可以尝试pprof看看具体是什么数据结构占了内存么？

[Niceies]

主要我们有些产品不是云上的，所以我们发版都需要做许多可靠性测试，发版没有这么快，目前看是跟不上社区的节奏，跑这个稳定性测试已经重跑了3次了，一直发不了版

[yhmo]

从某个版本分支出来的也很难定位问题。一般都是在某个版本上发现问题，然后后续版本解决问题。某个中间状态是没法做测试和验证的。

[Niceies]

那我先用最新的版本2.4.21版本跑下有没有内存增长的现象吧，内存泄漏我们这边卡的很严格，最新版本没有这个问题的话我再找领导们对齐下怎么处理了

[Niceies]

prometheus/client_golang#920
我查阅了下promethus的库记录指标的规则，这应该合理的，不用删除指标，我们这边需要调整下测试策略不用那么频繁增删集合，目前发现每增删4、5万个集合，mixcoord内存就会增长几十M左右，进程不退出就一直保留。

[yhmo]

"增删4、5万个集合"，你们的业务这么频繁地增删集合的么？多长时间内增删4万集合？

[Niceies]

我的监控系统曲线也碰到了这个问题，同样的2.4.17版本，如果我这边代码仓库合入这个改动重新编译是否可行（不清楚是否其他合并请求有关联改动），已经测试一段时间了，再升级版本到v2.4.21工作量比较大

[yhmo]

改动只有4行，只是增加了一小段逻辑，在出现error时把出错的task删除，可以pick过去，没有别的关联。
https://github.com/milvus-io/milvus/pull/38686/files