大规模底库搜索特征比对库Milvus（三），使用注意报错

milvus客户端超参数设置文档

1、docker 容器启动时 需要 --shm-size=“64g”

dorcker 启动会默认 设置/dev/shm的大小,默认值是64M，非常小，容器内运行程序，例如提取特征，会memory问题报错，或者 pytorch 提取特征 num_works 报错
可以用 free -g 查看电脑多少 g , 可以用，

docker run -it --name milvus_gpu_0.10.1 --gpus all \
--shm-size="64g" \
-p 19530:19530 \
-p 19121:19121 \
-v /milvus/db:/var/lib/milvus/db \
-v /milvus/conf:/var/lib/milvus/conf \
-v /milvus/logs:/var/lib/milvus/logs \
-v /milvus/wal:/var/lib/milvus/wal \
milvus_gpu_0.10.1:latest     #镜像名字：tag名字 ， 可以用docker ps 看到

server_config.yaml 客户端配置文件， cache_size 4G 会太小了，也可能报错
这里根据自己的服务器配置

2、 insert到milvus 一次性大小是 <=256M

status, ids = milvus.insert(collection_name=collection_name, records=g_vectors, ids=g_ids)

报错 ： Insert failed: Status(code=11, message='The amount of data inserted each time cannot exceed 256 MB')

修改你的代码： 一次插入到 milvus 表中数据不超过256M，计算如下

	例如2048 特征float32, (2048*4byte  /1024k) = 8k,一张图需8k内存，128张图片=1024k=1M,  
	所以256M 能一次插入 128张（1M） * 256M = 32768 张图片的特征
	
	例如512 人脸特征 （512*4byte  /1024k) = 2k,一张图需要2k内存，512张图片=1024k=1M，
	所以256M 能一次插入 512张（1M） * 256M = 131072 张图片的特征

3、milvus 表建立之后，构建索引查询报错

	WARN: increase temp memory to avoid cudaMalloc, or decrease query/add size (alloc 5888 B, highwater 268971520 B)
	WARN: increase temp memory to avoid cudaMalloc, or decrease query/add size (alloc 131072 B, highwater 268977408 B)
	Faiss assertion 'err == cudaSuccess' failed in void faiss::gpu::freeMemorySpace(faiss::gpu::MemorySpace, void*) at gpu/utils				/MemorySpace.cpp:72; details: Failed to cudaFree pointer 0x7efdec000000 (error 1 invalid argument)

官方报错说明回复
解决方法：
index_file_size 设置小一点，不要设置512 1024 ，
行人reid 2048维特征，可能需要更小一点32，如果出现WARN: increase temp memory to 建立的索引表，可能一直维持不动，一直在建立当中，正常2000w 15分钟以内建立索引表，搜索结束，很长时间都卡在那，
尝试 cache_size 变大 256G， index_file_size变小一点

4 github官网讨论区

插入 搜索等操作的介绍
https://github.com/milvus-io/milvus/issues/1763

	各种操作对查询操作的影响（一）插入操作对查询的影响
对于同一客户端，插入操作是阻塞操作，只有当插入操作完成后才能调	用查询接口，因此两种操作不会互相影响。
对于多客户端，假设客户端a频繁的插入操作，客户端b同时执行查询操作，milvus服务处理这些插入数据时会消耗部分CPU资源，因此会影响客户端b的查询性能。
插入数据后为了保证数据落盘，有时会调用flush操作，该操作是阻塞操作，会产生少量的CPU消耗以及磁盘IO，对其他客户端查询的性能影响较小。
对于插入操作引起的后台建索引行为也会严重影响查询操作，具体看后面一节。
（二）建索引操作对查询的影响
建索引有两种方式

a) 后台自动建索引, 主要的操作步骤是：

调用create_collection建立一个空集合
调用create_index给该集合指定一种索引（除IDMAP之外的任意一种索引）
多次调用insert插入数据，每当累计插入数据量达到index_file_size设定的大小，后台就会自动给新增的index_file_size大小的数据块建立索引
b) 手动调用create_index建索引, 主要的操作步骤是：

调用create_collection建立一个空集合
多次调用insert插入数据，这时由于没有给集合指定索引，所以不会在后台自动建立索引
手动调用create_index对整个集合的全部数据块建立索引，就算数据块的大小没有达到index_file_size设定的值，也会强制建索引，create_index是阻塞操作
分别在CPU和GPU两种模式下，两种建索引方式对查询的影响：

对于第1种方式：

CPU版本：建索引和查询都需要全占CPU资源，因此在后台建索引的时候，查询任务会等待索引完成后才能执行。
GPU版本：使用GPU建索引，其他的GPU或者CPU仍能执行查询任务，因此可以异步进行。
对于第2种方式：

CPU版本：由于create_index是阻塞操作，同一个客户端上要等该操作完成后才能查询。如果使用多客户端，另一个客户端可以执行查询，但由于建索引和查询都需要全占CPU资源，因此在milvus在运行建索引的时候，查询任务会等待索引完成后才能执行。
GPU版本：由于create_index是阻塞操作，同一个客户端上要等该操作完成后才能查询，建索引任务只使用一个GPU。如果使用多客户端，另一个客户端可以执行查询，使用其他的GPU或者CPU执行查询任务，因此可以异步进行。
（三）delete_by_id操作对查询的影响
该操作一般要连带调用flush以使得删除向量的操作生效，会产生少量的CPU消耗和磁盘IO，对其他客户端查询的性能影响较小
（四）compact操作对查询的影响
delete_by_id操作只是记录了一个被删向量的id列表，并没有真正从数据文件里把向量数据删除，为了清理掉被删向量，需要调用compact操作。
compact操作是很消耗资源的操作，其具体做的事情是：从原数据文件中提取出未被删除的向量数据，重新生成一份数据文件，如果该数据文件已经建好了索引，则把该索引文件删除，并重建一个新的索引文件。
compact是阻塞操作，由于既有大量磁盘IO也可能连带有建索引的操作，因此会严重影响其他客户端的查询性能。
（五）获取信息的操作对查询的影响
获取信息的接口包括：describe_collection, describe_index, get_vector_ids, get_vector_by_id，collection_info等等。
这些接口都是从meta里获取信息返回客户端，或者读取某些记录向量信息的小文件，因此比较轻量，对其他客户端查询性能的影响很小。
（六）preload_collection操作对查询的影响
preload_collection是把集合的数据预加载到缓存里，其功能相当于server_config.yaml里的preload_table这一项
milvus启动时，如果没有预加载集合的数据，那么对这个集合的查询就要经过将数据从磁盘读入缓存这一阶段，对于大数据量的集合来说会非常慢，因此在查询之前调用preload_table可以把数据先加载进磁盘，虽然总的耗时不变，但对于希望第一次查询就有好性能的场合很适用。

5 查看建立的表的信息

查看建立的表的信息官方文档安装查看