memory leak

[zzzzzhy]

Describe the bug
Milvus runs in the background using only one query, but the memory usage is increasing all the time. The data under tables directory is 1.5GB, the total data is 440,000, After a night on standby, the memory footprint became 2.7GB,The V10.1 runs for about 10 days and USES 33GB of memory
Index type IVFFLAT

Expected behavior
Use up to 1.5g of memory

Method of installation
Docker/gpu

Environment details
Centos7
Intel(R) Xeon(R) CPU E5-2640 v4 @ 2.40GHz
GeForce GTX 1080 x2
mem 252G

• Milvus version (master or released version)
  v0.10 v10.1 v10.2

Configuration file
default Configuration

Screenshots

[JinHai-CN]

Have you tried v0.10.2, which solved lots of issues.

[zzzzzhy]

Have you tried v0.10.2, which solved lots of issues.

Yes, that's what I'm using now v0.10.2,

This is the occupancy at this point, and during this time, I haven't used it

[shengjun1985]

If the cache is enough, Milvus will not release the raw data immediately after indexing.
Thus, it will occupy about 2 copies of space.

From the current information, I cannot judge whether the RES (3655M) was a normal value.
Would you like to provide more information?
(1) dim of the vector
(2) nlist of the index
(3) nq, topK of the query
(4) WAL enable or disable, WAL buffer_size

By the way, is it also read through RES that the maximum memory usage is 33G?

[zzzzzhy]

If the cache is enough, Milvus will not release the raw data immediately after indexing.
Thus, it will occupy about 2 copies of space.

From the current information, I cannot judge whether the RES (3655M) was a normal value.
Would you like to provide more information?
(1) dim of the vector
(2) nlist of the index
(3) nq, topK of the query
(4) WAL enable or disable, WAL buffer_size

By the way, is it also read through RES that the maximum memory usage is 33G?

(1)512 dim
(2)2048
(3)general nq==1 ,topK == 10
(4)wal enable is true,wal buffer_size==256MB

The maximum memory of 33G is the result of running for about 15 days,Now running 3 days of memory comes to 6GB

[shengjun1985]

Thank you for your important information.
We will investigate as soon as possible.

[shengjun1985]

In order to analyze the task execution, we added the completed tasks to a large circular queue.
Unexpectedly, this queue took up too much memory.

I retested it after committing the PR3609.
And the memory usage stabilized at 2.008G after 12 hours of continuous query.
Please wait for v0.10.3.
Thank you very much.

[shengjun1985]

v0.10.3 is released.
And we will continue to observe this phenomenon.
If you have more questions, please continue to contact our community.
Thank you very much.