Hey, Sorry; In the next release that should be in -h at least. The easiest way is to just start it with/without the option and diff the output of `stats settings` between the two.
On Sun, 13 Nov 2016, Bill Moseley wrote: > ok, I found the "modern" option by looking at the code. > In a few simple tests I can see slab memory is reclaimed. From what I see: > * Memcached will reclaim memory in the slab, but will leave two allocated > pages in the slab. > > * That freed memory can then be used for pages in other slabs. > > * If all items in the slab are reclaimed then "stats items" no longer shows > that slab. I wonder if that is correct because we can no longer see stats on > evicted items for > that slab. It's always been that way... just never fixed/changed it I guess? > * If more memory than specified with the -m command line argument was > malloced, then memory seems be be given back to the system after a reclaim > (down to -m setting). There's a "cache_memlimit" command that allows you to increase or decrease the memory limit at runtime. that's how the command works. > * Is there a good way to see how much memory has been reclaimed (and thus > available to other slabs)? | slab_global_page_pool | 32u | Slab pages returned to global pool for | | | | reassignment to other slab classes. | > Is the best way to subtract "bytes" from "total_malloced"? i.e. to > check how much "free" memory there is available for the cache. > Does the reclaim algorithm move items within the slab? That is, will it > reshuffle items from one page to another page so that the page can be > reclaimed? Or do all items in a > given page first need to expire before it can be reclaimed? See above. To answer your earlier questions: -I 4m should work a lot better with the new code. It doesn't screw up the smaller slab classes. > > On Fri, Nov 11, 2016 at 10:44 PM, Bill Moseley <[email protected]> wrote: > > > On Thu, Oct 13, 2016 at 11:32 PM, dormando <[email protected]> wrote: > I think this is fixed in 1.4.32. Been broken for a very long time > unfortunately. > > > Finally getting back to this. I'm testing with 1.4.33. Looks good, thanks. > > > I'm trying to understand all the new options. What does -o modern include? > > - modern: Enables 'modern' defaults. See release notes (highly recommended!). > > Which release notes should I be looking at? > > Or rather, can you provide guidance on what options to use? We are using > Memcached as a general cache so our value sizes and set frequency varies > quite a bit. I > suspect being able to reallocate slab space would be helpful in our case. > > We also have a need to store some larger (>1MB) items, too. (for example, -I > 4m) > > Thanks, > > > > On Sun, 25 Sep 2016, Bill Moseley wrote: > > > If I understand the documentation correctly, evicted_time should show > the seconds since the last access for the more recently evicted item. > > > > I'm seeing evicted_time for our production servers, but I'm not able > to have a value show up when testing. > > > > I have a slab class that can hold 10 items of the value I'm writing. > > > > I assume I would see an evicted_time doing this: > > 1. write a key and read it back > > 2. sleep 5 seconds. > > 3. write and read 10 random keys into the slab (quicly) > > 4. Notice that there has now been one eviction > > 5. read from the original key and get NOT FOUND > > I then see: > > > > STAT items:32:evicted 1 > > STAT items:32:evicted_nonzero 0 > > STAT items:32:evicted_time 0 > > > > > > Shouldn't I see evicted_time of 5 seconds since the item evicted was > last accessed about 5 seconds before it got evicted? > > > > I get the same result if I use no expires times or If I set it to, > say, 30 seconds. > > > > VERSION 1.4.25 > > > > > > -- > > Bill Moseley > > [email protected] > > > > -- > > > > --- > > You received this message because you are subscribed to the Google Groups > > "memcached" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to [email protected]. > > For more options, visit https://groups.google.com/d/optout. > > > > > > -- > > --- > You received this message because you are subscribed to the Google Groups > "memcached" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > > > > > -- > Bill Moseley > [email protected] > > > > > -- > Bill Moseley > [email protected] > > -- > > --- > You received this message because you are subscribed to the Google Groups > "memcached" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > > -- --- You received this message because you are subscribed to the Google Groups "memcached" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
