Here is nice page describing the issue: http://developers.nk.pl/tag/gc/
>The reality in nk.pl was that evictions of valid items happened hundreds >of times per second even though there were 50% of expired items, >because there is no inherent correlation between TTL and the pattern of usage. So basically if you have a plenty of items with short TTL, like 10-30 seconds, and then some items that need to live long, eg. 10 minutes, then the short living items will pile up at the beginning of the list, and memory will never be reclaimed, because GC will not pass the "barrier" created by long living items at the end (it starts from the end), because it'll clean only first expired item(s) found. In recent memcached release there is some mechanism to traverse all items from time to time... not sure how good it works, https://github.com/memcached/memcached/wiki/ReleaseNotes1431 Basically the memcache*d* extension for PHP was buggy and that's one of the reason for writing my project ... W dniu środa, 16 listopada 2016 22:52:55 UTC+1 użytkownik Jesper Louis Andersen napisał: > > > > On Wed, Nov 16, 2016 at 3:10 PM Slawomir Pryczek <slawe...@gmail.com > <javascript:>> wrote: > >> >> - Much better Garbage Collection mechanism, that isn't skipping items >> with short TTLs like LRU, so memory is not occupied with garbage data even >> if item TTLs differ a lot. >> >> > Could you expand on what this problem is? It sounds like a subtlety many > people implementing LRU will hit and overlook. Perhaps give an example of > what happens. > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
