请问为啥mix coordinator的networking data receiving rate长期保持在650mb/s?

[xiaobingxia-at]

我建立了一个cluster (2.4.17), 3 data nodes (15c60G), 16 indexing nodes (30c, 54G), 16 query nodes (13c, 114GB + local SSD). coordinator node (30c54G)
建立了100个collection，每个collection有10个partition(用了partition key)，总共导入了3-billion个1536-d vector，平均分布在每个collection， 和每个partition中。每个collection大概有30 million个vector。

没有任何数据导入，没有任何搜索进行。mix coordinator的CPU使用率一直保持在22%的“高位”，内存使用率在4G左右。但是诡异的是，networking data receiving rate长期保持在650mb/s。请问没有导入，没有搜索，coordinator是在读啥数据呢？

此时，因为各种原因，所有节点被rotate了。我要release/load这100个collection，无比的慢，大概20分钟才能完成一个collection的release和reload，我感觉是coordinator被瓶颈了？

请问为啥在这种情况下，coordinator会这么忙？coordinator是release load collection的瓶颈吗？有没有设置可以解决这个问题啊？

[xiaobingxia-at]

根据监控，是query node在发数据给coordinator。请问这是在发啥数据。

[bigsheeper]

querynode 的发送吞吐有多少呢？ 650mb/s 几乎都是来自 querynode 吗

[xiaofan-luan]

不是那么确定，几个猜测：

1. segment数目非常多，可能是因为导入小或者频繁flush，可能导致querycoord到datacoord的网络比较高
2. 也可能是querycoord到querynode的定期带宽比较高

可以联系一下bigsheeper, 一起profiling一下。我们目前已经解决了大部分多表场景下的故障恢复的速度，待发布。

[bigsheeper]

你好，方便的话提供下 coordinator 的 cpu、memory、goroutine pprof，我这边分析看看

[xiaobingxia-at]

coordinator 30 core, 54GB Memory. 不好意思请问如何拿到goroutine pprof, 对go的经验不是很多。

[xiaobingxia-at]

总共的segment数目在30000 - 40000左右。

[xiaobingxia-at]

我删除了31个collection，vector总数由3.5B，降低到了2.4B。这31个collection是没有load成功的，因为log一直显示segment not found，channel not available之类。剩下的69个collection，是花了一个晚上release又load过的。
删除之后，coordinator的networking receive rate瞬间由650mb/s 降低到了300mb/s, 然后query node突然变忙了，CPU使用率从接近0到了30-100%, networking receiving rate达到了200mb/s.

这是否表示，每个mivlus cluster目前不建议存储超过1B个vector （1536-d)

[bigsheeper]

"这是否表示，每个mivlus cluster目前不建议存储超过1B个vector （1536-d)"

不是的，我们有测过更高数量级的，load 这块我们正在解决；

go 的 pprof 使用如下命令采集：

go tool pprof {node_ip}:9091/debug/pprof/heap
go tool pprof {node_ip}:9091/debug/pprof/profile
go tool pprof {node_ip}:9091/debug/pprof/goroutine

三个命令分别对应内存、cpu、协程，命令执行后会提示生成一个 gz 文件，把文件发给我们就好； 最好 querynode、mixcoord 都采集一下，总共6个文件