Memory usage grows indefinitely about bigcache HOT 12 CLOSED

@tangtony I've been arbitrarily working on a test use case on this, I'll let you know what I come up with.

from bigcache.

Isn't this because with DefaultConfig() CleanWindow is 0, so expired entries are not removed from cache?

// Interval between removing expired entries (clean up).
// If set to <= 0 then no action is performed. Setting to < 1 second is counterproductive — bigcache has a one second resolution.
CleanWindow time.Duration

// DefaultConfig initializes config with default values.
// When load for BigCache can be predicted in advance then it is better to use custom config.
func DefaultConfig(eviction time.Duration) Config {
	return Config{
		Shards:             1024,
		LifeWindow:         eviction,
		CleanWindow:        0,
...

Afaik bigcache can store multiple versions of the same key in the buffer.

from bigcache.

@cristaloleg #154

from bigcache.

hello
Has the problem been solved？

from bigcache.

We got the same issue here

from bigcache.

Even with the following config I'm still seeing exponential growth in memory usage:

bigcache.Config{
  LifeWindow:   30 * time.Second,
  CleanWindow:  1 * time.Second,
}

They appear to be removed from cacheShard.hashmap, but cleanup aren't followed by a reduction in memory usage.

OS: Ubuntu 18.04.2 LTS

from bigcache.

@cristaloleg or @janisz is this unexpected behaviour? Because we don't use pointers, there's no garbage collection runs against allocated objects, so no memory would ever be freed.

https://github.com/allegro/bigcache#how-it-works

from bigcache.

I'm curios what will happen if @mingard will invoke https://godoc.org/runtime#GC once per minute.

That's a really strange behaviour that Bigcache still allocates memory.

from bigcache.

@cristaloleg We've done a lot of investigation and it looks like even with GC calls, the system isn't freeing up memory.

We ended up looking at the way bigcache handles eviction, and it appears that it's a little lazy (in a good way). Whilst memory is marked as free, it doesn't perform eviction until a new item inserted.

This was confirmed by digging through similar issues to find this comment: #31 (comment)

It looks like this is covered in a blog post somewhere, but it feels like something that is worthy of the README.

from bigcache.

Thanks for the information, looks like you've observing this behaviour: https://utcc.utoronto.ca/~cks/space/blog/programming/GoNoMemoryFreeing

Yep, mentioning such behaviour in README is a good idea, do you want to try? 😉

from bigcache.

Fixed in #154

from bigcache.

I think this is not the behavior. You can disable it on go 1.12 with GODEBUG=madvdontneed=1 flag or use go 1.10 and still go OOM while doing OP test. I worked around it by limiting overall bigcache memory with HardMaxCacheSize but it is not ideal as it reduces performance. Maybe its because what @mdogan noted?

Afaik bigcache can store multiple versions of the same key in the buffer.

is this the case? if so what happens when we call to get the key? do we get the last version? if so why do we store the old ones?

from bigcache.