为什么我配置的mmap功能未生效？

[midonKing]

我按照https://milvus.io/docs/mmap.md的指导在配置文件中配置了mmap参数如下，已测试在不启用mmap的情况下，大约能加载一千万左右1024维度的集合，然后我修改了下配置，启用qn节点的mmap，但这个时候我再追加350w的集合时，已经加载不进去了

querynode配置如下：
queryNode:
affinity: {}
disk:
enabled: true
size:
enabled: false
enabled: true
extraEnv: []
heaptrack:
enabled: false
mmap:
vectorField: true # Enable mmap for loading vector data
vectorIndex: true # Enable mmap for loading vector index
scalarField: true # Enable mmap for loading scalar data
scalarIndex: true # Enable mmap for loading scalar index
mmapDirPath: /data/milvus_mmap
nodeSelector: {}
profiling:
enabled: false
replicas: 3
resources:
limits:
cpu: 4
memory: 16Gi
requests:
cpu: 2
memory: 8Gi
tolerations: []

并且我在attu上为这个350w的新集合设置了属性mmap.enabled为true

[yhmo]

加载不进去是报什么错？query node日志里有什么warning

[midonKing]

感谢回复！

查了下qn节点的日志，是oom错误，具体信息如下

[2025/03/03 06:15:14.733 +00:00] [WARN] [segments/segment_loader.go:273] ["request resource failed"] [traceID=bb68c7fedc0ceb0d2fb592e82ba7af71] [collectionID=456385180985984987] [segmentType=Sealed] [requestSegments="[456385180997144976]"] [preparedSegments="[456385180997144976]"] [error="load segment failed, OOM if load, maxSegmentSize = 2928.5486640930176 MB, memUsage = 13551.79296875 MB, predictMemUsage = 16480.341632843018 MB, totalMem = 16384 MB thresholdFactor = 0.900000"]

[yhmo]

这行日志前面应该还有一行Info，“predict memory and disk usage while loading (in MiB)”，那行日志显示了它估计的内存和磁盘用量。
如果mmap确实是enabled的话，它只会计算磁盘的用量而不会计算内存用量。而你的日志里predictMemUsage = 16480这是预估了内存用量的，我觉得这个表的mmap应该没有enabled。

你用attu看一下那张表的mmap.enabled有没有设值：

如果是false的，就用这个接口设成true:

milvus_client.alter_collection_properties(collection_name, properties={"mmap.enabled":True})

另外，你用这个接口把这个表的向量字段的"mmap.enabled"设为true看看:

milvus_client.alter_collection_field(collection_name,field_name="xxx",field_params={"mmap.enabled":True})

设置mmap之前先把collection release
另外，mmap对DiskIndex和GPU index无效

[midonKing]

感谢解答！

我按照你提供的方式，首先确认了集合是未加载状态的，然后我使用alter_collection_properties和alter_collection_field将集合属性和向量字段属性修改成mmap.enabled': 'True'，修改后的集合属性如下：

然后我用attu加载，但是加载时只有一个QN节点在加载，他的负载比较高

我等待一段时间后，大约加载45%左右就失败了，这个QN节点的日志信息如下：

[2025/03/04 01:51:32.735 +00:00] [WARN] [delegator/delegator_data.go:465] ["worker failed to load segments"] [traceID=ef3318f43e99b9eeef7496bf24680ff4] [collectionID=456385181002474002] [channel=by-dev-rootcoord-dml_4_456385181002474002v0] [replicaID=456385181566107658] [workID=155] [segments="[456385181020631277]"] [error="Assert "!mapping.count(kv.key())" => repeat key(mmap.enabled) in protobuf at /workspace/source/internal/core/src/common/protobuf_utils.h:35\n"]
[2025/03/04 01:51:32.735 +00:00] [WARN] [querynodev2/services.go:474] ["delegator failed to load segments"] [traceID=ef3318f43e99b9eeef7496bf24680ff4] [collectionID=456385181002474002] [partitionID=456385181002474003] [shard=by-dev-rootcoord-dml_4_456385181002474002v0] [segmentID=456385181020631277] [level=L1] [currentNodeID=151] [dstNodeID=155] [error="Assert "!mapping.count(kv.key())" => repeat key(mmap.enabled) in protobuf at /workspace/source/internal/core/src/common/protobuf_utils.h:35\n"]
[2025/03/04 01:51:32.735 +00:00] [WARN] [cluster/worker.go:105] ["failed to call LoadSegments via grpc worker"] [traceID=ef3318f43e99b9eeef7496bf24680ff4] [workerID=155] [error="Assert "!mapping.count(kv.key())" => repeat key(mmap.enabled) in protobuf at /workspace/source/internal/core/src/common/protobuf_utils.h:35\n"]
[2025/03/04 01:51:32.735 +00:00] [WARN] [delegator/delegator_data.go:465] ["worker failed to load segments"] [traceID=ef3318f43e99b9eeef7496bf24680ff4] [collectionID=456385181002474002] [channel=by-dev-rootcoord-dml_4_456385181002474002v0] [replicaID=456385181566107658] [workID=155] [segments="[456385181027133599]"] [error="Assert "!mapping.count(kv.key())" => repeat key(mmap.enabled) in protobuf at /workspace/source/internal/core/src/common/protobuf_utils.h:35\n"]
[2025/03/04 01:51:32.735 +00:00] [WARN] [querynodev2/services.go:474] ["delegator failed to load segments"] [traceID=ef3318f43e99b9eeef7496bf24680ff4] [collectionID=456385181002474002] [partitionID=456385181002474003] [shard=by-dev-rootcoord-dml_4_456385181002474002v0] [segmentID=456385181027133599] [level=L1] [currentNodeID=151] [dstNodeID=155] [error="Assert "!mapping.count(kv.key())" => repeat key(mmap.enabled) in protobuf at /workspace/source/internal/core/src/common/protobuf_utils.h:35\n"]
[2025/03/04 01:51:32.737 +00:00] [INFO] [segments/segment_loader.go:1415] ["predict memory and disk usage while loading (in MiB)"] [traceID=ef3318f43e99b9eeef7496bf24680ff4] [collectionID=456385181002474002] [maxSegmentSize(MB)=2434.1502161026] [committedMemSize(MB)=0] [memLimit(MB)=16384] [memUsage(MB)=12614.66796875] [committedDiskSize(MB)=0] [diskUsage(MB)=0] [predictMemUsage(MB)=15048.8181848526] [predictDiskUsage(MB)=1.9169197082519531] [mmapFieldCount=4]
[2025/03/04 01:51:32.737 +00:00] [WARN] [segments/segment_loader.go:479] ["no sufficient resource to load segments"] [traceID=ef3318f43e99b9eeef7496bf24680ff4] [segmentIDs="[456385181023796560]"] [error="load segment failed, OOM if load, maxSegmentSize = 2434.1502161026 MB, memUsage = 12614.66796875 MB, predictMemUsage = 15048.8181848526 MB, totalMem = 16384 MB thresholdFactor = 0.900000"]
[2025/03/04 01:51:32.737 +00:00] [WARN] [segments/segment_loader.go:273] ["request resource failed"] [traceID=ef3318f43e99b9eeef7496bf24680ff4] [collectionID=456385181002474002] [segmentType=Sealed] [requestSegments="[456385181023796560]"] [preparedSegments="[456385181023796560]"] [error="load segment failed, OOM if load, maxSegmentSize = 2434.1502161026 MB, memUsage = 12614.66796875 MB, predictMemUsage = 15048.8181848526 MB, totalMem = 16384 MB thresholdFactor = 0.900000"]

我奇怪的是，为什么只在一个QN节点上加载呢，总共有三个QN节点

[midonKing]

从attu上看，这个集合的MMAP属性已经是true了

[yhmo]

你把表先release，然后再load，然后load失败之后你用这个脚本把集群的日志提取出来打包贴上来： https://github.com/milvus-io/milvus/tree/master/deployments/export-log

[midonKing]

@yhmo 另外我发现，如果同时将向量字段的mmap.enabled和集合的mmap.enabled同时设置为true，就会报错如下

单独设置集合的mmap则不会， 我搜了下可能是mmap.enabled参数被多次定义？

但如果只单独设置集合的mmap为true，则还是会报错OOM，这个问题已经困扰我两天了，崩溃T_T...

[midonKing]

这是我的QN节点参数信息：
queryNode:
affinity: {}
disk:
enabled: true
size:
enabled: false
enabled: true
extraEnv: []
heaptrack:
enabled: false
mmap:
scalarField: true
scalarIndex: true
vectorField: true
vectorIndex: true
nodeSelector: {}
profiling:
enabled: false
replicas: 3
resources:
limits:
cpu: 4
memory: 16Gi
requests:
cpu: 2
memory: 8Gi
tolerations: []

我之前怀疑配置信息中的chunkCache与mmap.enabled有冲突，所以去掉了，chunkCache: true这个我之前加上的时候也是一样的报错多次定义

[midonKing]

@yhmo 你好，能麻烦提供一个可以正常运行 mmap功能yaml 配置文件给我参考下吗？我想看看是不是我的配置文件中存在问题，感谢！

[yhmo]

你的yaml设置就没什么问题，chunkCache就算不设默认也是true的。
这张表的索引是什么类型？不会是DiskIndex吧？

[midonKing]

@yhmo 索引是HNSW，m16，efConstruction为512
如果不是配置文件的问题的话，我这边实在想不通还有哪些地方存在问题了，这个能提一个bug排查吗？

[yhmo]

你提issue排查恐怕也看不出什么。

先按我说的，你把表先release，然后再load，然后load失败之后你用这个脚本把集群的日志提取出来打包贴上来： https://github.com/milvus-io/milvus/tree/master/deployments/export-log

[midonKing]

@yhmo 您好，我按照你的建议导出了日志，请查收附件。

这个日志是24小时的，3-6日10点10分左右，我用hello_milvus_1000这个集合，在只启用了properties={"mmap.enabled":True}下进行导入，失败了，第二次在10点20左右，我启用了properties={"mmap.enabled":True}，并且embeddings向量字段也启用了field_params={"mmap.enabled":True})，依然失败了，麻烦帮忙分析一下日志，非常感谢！
2025030601.tar.gz

[yhmo]

你的“hello_milvus_1000”这张表里，有个字段确实有重复的mmap.enabled

fieldID:102 name:\"embeddings\" data_type:FloatVector type_params:{key:\"dim\" value:\"1024\"} type_params:{key:\"mmap.enabled\" value:\"True\"} type_params:{key:\"mmap.enabled\" value:\"true\"}

而正常设置mmap的字段只有一个mmap.enabled

fieldID:101 name:\"vector\" data_type:FloatVector type_params:{key:\"mmap.enabled\" value:\"True\"} type_params:{key:\"dim\" value:\"1024\"}

重复的mmap.enabled在querynode导致了大量的报错。但我复现不出这种重复mmap.enabled的情况。
我就算在add_field和alter_collection_field里同时设置了"mmap.enabled":True 都不会出现你这种情况。

schema.add_field(field_name="vector", datatype=DataType.FLOAT_VECTOR, dim=dim, mmap_enabled=True)

client.alter_collection_properties(collection_name, properties={"mmap.enabled":True})
client.alter_collection_field(collection_name, field_name="vector",field_params={"mmap.enabled":True})
client.alter_index_properties(collection_name, index_name="vector", properties={"mmap.enabled":True})

你设置这个表的mmap时是怎么操作的？

[xiaofan-luan]

改colelction field没用的，你要改的事索引的mmap enable。

mmap:
scalarField: true
scalarIndex: true
vectorField: true
vectorIndex: true
你这个都改了，集群生效，重启集群应该也都能work

[midonKing]

@yhmo 我试了下删掉整个集群，包括etcd、PVC等等，重新部署后尝试还是会有这个重复mmap.enabled，我具体的操作顺序是
helm部署集群（QN节点启用MMAP）>导入测试数据集合>load>load失败>修改properties={"mmap.enabled":True}>再次尝试加载失败（此时检查日志只有OOM报错，没有重复mmap的报错）>修改field_params={"mmap.enabled":True})>再次加载失败（此时开始出现mmap重复建报错）

[xiaofan-luan]

或者collection.alter_index(
index_name="vector_index", # 替换为您的向量索引名称
extra_params={"mmap.enabled": True} # 为索引启用mmap
)

需要重新加载
注意，mmap只对hnsw和ivf生效

[midonKing]

@yhmo 我重新部署集群后，先加载少量数据，然后再启用集合的mmap enable，这样规避了重复enable属性的问题，但是我发现了另一个奇观的现象，按照您之前的解释“mmap确实是enabled的话，它只会计算磁盘的用量而不会计算内存用量”，但我观察了下日志和mmap的存储路径，首先确认这个集合在启用mmap之后应该是生效了，在mmap默认路径下已经产生了文件，与集合的创建时间是对应的，但在QN节点日志上，还是有这个"predict memory and disk usage while loading (in MiB)"的报错，请问下这种情况下，mmap是否是正常生效的？

[yhmo]

我看你的segment size很大，那个maxSegmentSize达到4381MB，每个segemnt有很多文件组成，在load segment的时候是并行加载的，所需的峰值内存呈倍数，一般预估都有2到3倍。从S3读取数据时，数据要在内存里展开，由于GO和C++混合，临时数据有可能被copy，峰值会很高。所以你的16GB的内存容量很容易触发预估报警。

"predict memory and disk usage while loading (in MiB)"这行日志是这里打印的

milvus/internal/querynodev2/segments/segment_loader.go

Line 1427 in 972e470

log.Info("predict memory and disk usage while loading (in MiB)",

它是显示总的状态。

还有一条DEBUG级别日志在这里

milvus/internal/querynodev2/segments/segment_loader.go

Line 1412 in 972e470

log.Debug("segment resource for loading",

这条日志显示每个segment的预估值，你如果打开debug日志就能看到。

[midonKing]

感谢回复，请问这个maxSegmentSize在哪里可以限制大小呢？我看了下官方文档上没有关于这个参数的配置信息

[xiaofan-luan]

默认应该都是1G左右，你用的什么版本的Milvus？用2.4.23或者2.5.6这些最新版本可能能解决问题

[yhmo]

控制segment size的参数在milvus.yaml的 dataCoord.segment.maxSize，一般默认是1GB

milvus/configs/milvus.yaml

Line 525 in 972e470

maxSize: 1024 # The maximum size of a segment, unit: MB. datacoord.segment.maxSize and datacoord.segment.sealProportion together determine if a segment can be sealed.