Aerospike pods consume a lot of RAM during migration, which is not released after migration about aerospike-server

[kportertx]

I have seen this post which explains why does it consumes this much memory, but i don't see why this memory is not released after migration is done.

That's a very stale KB article. The issue with threads loading entire partitions into memory was addressed back in Aerospike 3.x. I've requested this be reviewed internally.

[kportertx]

Could you provide the output of:

ipcs

If the migrations were from decreasing the cluster size, it is possible that the primary index added one or more stages. The primary index is allocated in 1 GiB stages (by default). Primary index memory isn't ever freed back to the OS, the free space in the stages is managed by Aerospike.

[mdnfiras]

any ideas what could be the problem here? we are still experiencing this. should we update to latest version?

[mdnfiras]

@kportertx thanks for the response! right now there are no migrations happening, and the output of ipcs in all 3 nodes is:

# ipcs

------ Message Queues --------
key        msqid      owner      perms      used-bytes   messages    

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status      

------ Semaphore Arrays --------
key        semid      owner      perms      nsems     

[kportertx]

Oh, right, this is Aerospike Community so ipcs will not show primary index stages because the primary index isn't stored in shared memory. We do not have a metric that shows how many stages the primary index has allocated, so I cannot definitively say that this is the cause in your case, but I believe it is the most likely explanation.