standalone cpu 占用300%左右，系统持续告警

[gangren-user]

docker单机部署，docker compose xxxx.yaml的方式启动，都是默认配置

在我的milvus运行过程当中，看到standalone节点的cpu占用率一直很高（300%左右），系统一直报警
服务器只运行了milvus数据库，而且docker里面也没有其他容器在运行，我原本以为是我的业务侧连接池连接数量太多导致的，最终将业务侧连接池改为1，发现CPU并没有降低
在其他QA问答中有提到说是因为数据表开启了相关操作，例如mmap_enable等，我的数据集里面并没有开启mmap_enable，但是我开启了enable_match、enable_analyzer选项
从官方文档手册中这两个参数的说明，只提到了会影响存储资源，并没有提到会影响CPU，同时我查看了我的docker内存情况，总共15G，standalone占用了11G，其他容器总占用不超过500M

这里不清楚为什么会出现CPU一直飙高的情况，一直也降不下来

[gangren-user]

内部环境部署，日志不方便导出上传到公网

[yhmo]

用Attu这个工具观察一下Tasks面板，看有没有index task或者compaction task。如果有持续的数据insert/upsert/delete，就会持续触发这两种任务。
https://github.com/zilliztech/attu
安装运行Attu

docker pull zilliz/attu:v2.6.1
docker run -p 8000:3000 -e MILVUS_URL=localhost:19530 zilliz/attu:v2.6.1

浏览器里打开：http://localhost:8000/

[gangren-user]

确实是因为查询产生的CPU飙高，我目前查询频率高是由健康检查导致的，我的健康检查是通过search查询数据库，看是否能否正常返回，但是search调用的比较频繁，可能本身search查询消耗也比较重（根据观察，单次调用search或hybrid_search，CPU会瞬间飙高(280%左右)，查询结束后又会瞬间降低），而且我是多台机器都有健康检查这个动作

在除了降低健康检查的调用频率之外，有没有什么方法，既能检测到milvus数据库的健康状态或者是可用状态，又能降低CPU占用，因为有时候milvus节点确实会宕掉，或者节点在正常运行，但是执行search检索的时候（可能是因为数据的原因或者是其他原因）会阻塞或报错，确实需要实时去检测milvus的健康状态

我目前使用的是milvus2.5版本

[yhmo]

search或hybrid_search cpu高很正常，它在充分利用你的cpu以最短的时间计算出结果。standalone宕掉最常见的原因是OOM，可以观察连续查询过程中内存的用量是否逼近Limit上限，或者改用较节省内存的IVF_PQ/IVF_SQ8索引(召回率比HNSW略低)

[gangren-user]

query操作没有通过向量来匹配，是不是不消耗CPU计算资源（根据验证结果来看，还是会造成CPU消耗）
我目前的目标是希望降低CPU的资源消耗，主要方向是从milvus健康状态检查以及milvus中的数据实时同步刷新操作，这两个方向来降低search操作
我目前数据变化实时更新milvus操作，是通过query先查询出来和数据库最新数据做对比，有变化的情况下才做insert/upsert/delete，没有变化则跳过，希望能够从非业务检索层面操作，降低CPU计算

[yhmo]

query要做条件表达式解析，根据条件去各个segment里找数据位置，一般是做大量bitset匹配，或者做bloom filter运算，这个有一定量的运算量，数据越多越难找。
降低cpu消耗有何实际意义，硬件资源就是用来压榨性能的。
做数据更新的话，先query再做upsert也行，或者直接upsert。
一个upsert等于一个insert + 一个delete操作。先query再做upsert会慢一些，可以避免一些多余的upsert操作。直接全都upsert快一点，不过会造成一些不必要的upsert操作，写放大。

[xiaofan-luan]

query操作没有通过向量来匹配，是不是不消耗CPU计算资源（根据验证结果来看，还是会造成CPU消耗） 我目前的目标是希望降低CPU的资源消耗，主要方向是从milvus健康状态检查以及milvus中的数据实时同步刷新操作，这两个方向来降低search操作 我目前数据变化实时更新milvus操作，是通过query先查询出来和数据库最新数据做对比，有变化的情况下才做insert/upsert/delete，没有变化则跳过，希望能够从非业务检索层面操作，降低CPU计算

Query的开销也不小，直接用upsert即可