0

i'm using redis and noticed that it crashes with the following error :

MISCONF Redis is configured to save RDB snapshots

I tried the solution suggested in this post

but everything seems to be OK in term of permissions and space.

htop command tells me that redis is consuming 70% of RAM. i tried to stop / restart redis in order to flush but at startup, the amount of RAM used by redis was growing up dramatically and stops around 66%. I'm pretty sure at this moment no processus was using any redis instance !

what happens there ?

Dany M
  • 760
  • 1
  • 13
  • 28
  • How much time did you wait when you start your Redis server ? For example, after 5 hours is it still like what you described with releasing no memory ? – anL Jan 12 '18 at 18:04
  • immediatly after restart – Dany M Jan 15 '18 at 08:49

1 Answers1

0

The growing up ram issue is an expected behaviour of Redis at first data load, after restarts, writing the data to disk (snapshot process). Redis tends to allocate memory as much as it can unless you don't use "maxmemory" option at your conf file.

It allocates memory but not release immediately. Sometimes it takes hours, I saw such cases.

Well known fact about Redis is that, it can allocate memory up to twice size of the dataset it keeps.

I suggest you to wait couple of hours without any restart (Redis can work in this time, get/set operations etc.) and keep watching the memory.

Please check that too

Redis will not always free up (return) memory to the OS when keys are removed. This is not something special about Redis, but it is how most malloc() implementations work. For example if you fill an instance with 5GB worth of data, and then remove the equivalent of 2GB of data, the Resident Set Size (also known as the RSS, which is the number of memory pages consumed by the process) will probably still be around 5GB, even if Redis will claim that the user memory is around 3GB. This happens because the underlying allocator can't easily release the memory. For example often most of the removed keys were allocated in the same pages as the other keys that still exist.

anL
  • 1,073
  • 1
  • 11
  • 31