根据milvus 资源限制的官网，我们得出百万数据资源限制。
1.dev 环境 对接不同的配置最大的qps 如下(dev的机器内存很小)
2.于是认为当前的性能是匹配的，然后加上资源限制，配置
压测结果如下
{
"run_id": "13292982fee74f64a6352886bd2e48c1",
"task_label": "13292982fee74f64a6352886bd2e48c1",
"results": [{
"metrics": {
"max_load_count": 0,
"load_duration": 1921.7745,
"qps": 1562.3437,
"serial_latency_p99": 0.0059,
"recall": 0.5972,
"ndcg": 0.6318,
"conc_num_list": [1, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50, 55, 60, 65, 70, 75, 80, 85, 90, 95, 100],
"conc_qps_list": [195.3319, 790.9781, 1080.3159, 1373.9811, 1432.1278, 1440.8132, 1433.1897, 1491.7838, 1493.107, 1481.4041, 1502.0799, 1508.3413, 1530.3134, 1521.0524, 1547.9447, 1549.8126, 1555.2589, 1562.3437, 1544.5287, 1552.6871, 1545.3059],
"conc_latency_p99_list": [0.004279492217302322, 0.004500870367884636, 0.004731282425113022, 0.005114195805042982, 0.005836073917336762, 0.006389325391501189, 0.006925125846266747, 0.008031808454543352, 0.006713001053780317, 0.007038204529695212, 0.008382701979205012, 0.005965838904678822, 0.006431116539426148, 0.010065575167536735, 0.007617924952134489, 0.007334843980520961, 0.009211420500651001, 0.00817261971924454, 0.006796466001681981, 0.006674074270576239, 0.00732990248594433]
},
"task_config": {
"db": "Milvus",
"db_config": {
"db_label": "2024-08-20T10:48:40.903270",
"uri": "**********"
},
"db_case_config": {
"index": "IVF_FLAT",
"metric_type": "COSINE",
"nlist": 1024,
"nprobe": 5
},
"case_config": {
"case_id": 50,
"custom_case": null,
"k": 100,
"concurrency_search_config": {
"num_concurrency": [1, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50, 55, 60, 65, 70, 75, 80, 85, 90, 95, 100],
"concurrency_duration": 30
}
},
"stages": ["drop_old", "load", "search_serial", "search_concurrent"]
},
"label": ":)"
}
],
"file_fmt": "result_{}_{}_{}.json"
}
很诧异，开始排查问题的所在：
1.第一先考虑的是不是obs 的问题
于是又在dev环境加上资源限制，得到的结果：
那就不是obs 的问题
2.考虑一下是不是pulsar 的问题，在这个过程，要感谢一下社区，问了得到明确的结论是pulsar 只落盘，不参与数据的查询操作。但是得出结论
还是保持质疑，刚好dev 环境没有资源，不能限制pulsar ，发现性能还是很差，所有排除pulsar问题
3.后来运维同学通过监控发现queryNode CPU 涨的很快，就将资源改成
6c 8g ，果然性能提高到无资源限制的qps 维度。
4.扩展一下：再最终到生产环境上线发现，资源并没有达到预期的qps (需要关上认证才能压测哦)
如下图
这个时候就非常诧异，随机就对比sit 环境资源配置和grafana 资源消耗情况
最终同时发现 proxy pod 资源消耗和queryNode pod 是正相关关系，然后看了一下sit 环境的资源配置，不知道在哪次的修改中将资源改为8c 16g。
故将生产环境改为proxy 8c16g .queryNode:8 core 16 GB 副本数为1
压测结果如下
qps 达到7400+！！！
然后逐渐扩容querynode 为3 ,性能如下
性能并没有提高多少！
最后逐渐扩容querynode 为5 ,性能如下
性能并没有提高多少！
额外的例子：3 proxy 1querynode
性能并没有提高多少！
总结：1。官网提供的资源配置，应该是以数据为主的，但是如果对milvus 有性能要求，应该提高 proxy 和 queryNode 的资源。它们的资源是呈正相关的，单纯扩容其中某一个是不能实现qps 性能的提升的。同时修改的核心是CPU,其实是开启线程，进行I/O。友情提示：还是看各位看官，场景实际的数据量 和 并发数，动态更改
