(memory_requested / (chunk_size * chunk_used)) * 100
is roughly the storage overhead of memory used in the system. the rest is
free memory, which should be measured separately. If you're getting
evictions in class A but there's too much free memory in classes C, D, etc
then you have a balance issue. for example. An efficiency stat which just
adds up the total pages doesn't tell you what to do with it.
On Sat, 4 Jul 2020, Shweta Agrawal wrote:
> > I'll need the raw output from "stats items" and "stats slabs". I don't
> > think that efficiency column is very helpful. ohkay no worries. I can get
> > by Tuesday and will share.
>
> Efficiency for each slab is calcuated as
> (("stats slabs" -> memory_requested) / (("stats slabs" -> total_pages) *
> page_size)) * 100
>
>
> Attaching script which has calculations for the same. The script is from
> memcahe repo with additional calculation for efficiency.
> Will it be possible for you to verify if the efficiency calculation is
> correct?
>
> Thank you,
> Shweta
>
> On Saturday, July 4, 2020 at 1:08:23 PM UTC+5:30, Dormando wrote:
> ah okay.
>
> I'll need the raw output from "stats items" and "stats slabs". I don't
> think that efficiency column is very helpful.
>
> On Fri, 3 Jul 2020, Shweta Agrawal wrote:
>
> >
> >
> > On Saturday, July 4, 2020 at 9:41:49 AM UTC+5:30, Dormando wrote:
> > No attachment
> >
> > On Fri, 3 Jul 2020, Shweta Agrawal wrote:
> >
> > >
> > > Wooo...so quick. :):)
> > > > Correct, close. It actually uses more like 3 512k chunks
> and then one
> > > > smaller chunk from a different class to fit exactly 1.6MB.
> > > I see.Got it.
> > >
> > > >Can you share snapshots from "stats items" and "stats slabs"
> for one of
> > > these instances?
> > >
> > > Currently I have summary of it, sharing the same below. I can
> get snapshot by Tuesday as need to request for it.
> > >
> > > pages have value from total_pages from stats slab for each
> slab
> > > item_size have value from chunk_size from stats slab for each
> slab
> > > Used memory is calculated as pages*page size ---> This has to
> corrected now.
> > >
> > >
> > > prod_stats.png
> > >
> > >
> > > > 90%+ are perfectly doable. You probably need to look a bit
> more closely
> > > > into why you're not getting the efficiency you expect. The
> detailed stats
> > > > output should point to why. I can help with that if it's
> confusing.
> > >
> > > Great. Will surely ask for your input whenever I have
> question. It is really kind of you to offer help.
> > >
> > > > Either the slab rebalancer isn't keeping up or you actually
> do have 39GB
> > > > of data and your expecations are a bit off. This will also
> depending on
> > > > the TTL's you're setting and how often/quickly your items
> change size.
> > > > Also things like your serialization method / compression /
> key length vs
> > > > data length / etc.
> > >
> > > We have much less data than 39 GB. As after facing evictions,
> it has been always kept higher than expected data-size.
> > > TTL is two days or more.
> > > From my observation items size(data-length) is in the range
> of 300Bytes to 500K after compression.
> > > Key length is in the range of 40-80 bytes.
> > >
> > > Thank you,
> > > Shweta
> > >
> > > On Saturday, July 4, 2020 at 8:38:31 AM UTC+5:30, Dormando
> wrote:
> > > Hey,
> > >
> > > > Putting my understanding to re-confirm:
> > > > 1) Page size will always be 1MB and we cannot change
> it.Moreover, it's not required to be changed.
> > >
> > > Correct.
> > >
> > > > 2) We can store items larger than 1MB and it is done
> by combining chunks together. (example: let's say item size: ~1.6MB -->
> 4 slab
> > > chunks(512k slab) from
> > > > 2 pages will be used)
> > >
> > > Correct, close. It actually uses more like 3 512k
> chunks and then one
> > > smaller chunk from a different class to fit exactly
> 1.6MB.
> > >
> > > > We use memcache in production and in past we saw
> evictions even when free memory was present. Also currently we use cluster
> with
> > 39GB RAM in
> > > total to
> > > > cache data even when data size we expect is ~15GB to
> avoid eviction of active items.
> > >
> > > Can you share snapshots from "stats items" and "stats
> slabs" for one of
> > > these instances?
> > >
> > > > But as our data varies in size, it is possible to
> avoid evictions by tuning parameters: chunk_size, growth_factor,
> slab_automove.
> > Also I
> > > believe memcache
> > > > is efficient and we can reduce cost by reducing
> memory size for cluster.
> > > > So I am trying to find the best possible memory size
> and parameters we can have.So want to be clear with my understanding
> and
> > calculations.
> > > >
> > > > So while trying different parameters and putting all
> calculations, I observed that total_pages * item_size_max > physical
> memory for
> > a
> > > machine. And from
> > > > all blogs,and docs it didnot match my understanding.
> But it's clear now. Thanks to you.
> > > >
> > > > One last question: >From my trials I find that we can
> achieve ~90% storage efficiency with memcache. (i.e we need 10MB of
> physical
> > memory to
> > > store 9MB of
> > > > data. Do you recommend any idle memory-size interms
> of percentage of expected data-size?
> > >
> > > 90%+ are perfectly doable. You probably need to look a
> bit more closely
> > > into why you're not getting the efficiency you expect.
> The detailed stats
> > > output should point to why. I can help with that if
> it's confusing.
> > >
> > > Either the slab rebalancer isn't keeping up or you
> actually do have 39GB
> > > of data and your expecations are a bit off. This will
> also depending on
> > > the TTL's you're setting and how often/quickly your
> items change size.
> > > Also things like your serialization method /
> compression / key length vs
> > > data length / etc.
> > >
> > > -Dormando
> > >
> > > > On Saturday, July 4, 2020 at 12:23:09 AM UTC+5:30,
> Dormando wrote:
> > > > Hey,
> > > >
> > > > Looks like I never updated the manpage. In the
> past the item size max was
> > > > achieved by changing the slab page size, but
> that hasn't been true for a
> > > > long time.
> > > >
> > > > From ./memcached -h:
> > > > -m, --memory-limit=<num> item memory in
> megabytes (default: 64)
> > > >
> > > > ... -m just means the memory limit in
> megabytes, abstract from the page
> > > > size. I think that was always true.
> > > >
> > > > In any recentish version, any item larger than
> half a page size (512k) is
> > > > created by stitching page chunks together. This
> prevents waste when an
> > > > item would be more than half a page size.
> > > >
> > > > Is there a problem you're trying to track down?
> > > >
> > > > I'll update the manpage.
> > > >
> > > > On Fri, 3 Jul 2020, Shweta Agrawal wrote:
> > > >
> > > > > Hi,
> > > > > Sorry if I am repeating the question, I
> searched the list but could not find definite answer. So posting it.
> > > > >
> > > > > Memcache version: 1.5.10
> > > > > I have started memcahce with option: -I 4m
> (setting maximum item size to 4MB).Verified it is set by command stats
> settings ,
> > I can
> > > see STAT
> > > > item_size_max
> > > > > 4194304.
> > > > >
> > > > > Documentation from git repository here stats
> that:
> > > > >
> > > > > -I, --max-item-size=<size>
> > > > > Override the default size of each slab page.
> The default size is 1mb. Default
> > > > > value for this parameter is 1m, minimum is
> 1k, max is 1G (1024 * 1024 * 1024).
> > > > > Adjusting this value changes the item size
> limit.
> > > > > My understanding from documentation is this
> option will allow to save items with size till 4MB and the page size for
> each
> > slab will
> > > be 4MB
> > > > (as I set it as
> > > > > -I 4m).
> > > > >
> > > > > I am able to save items till 4MB but the
> page-size is still 1MB.
> > > > >
> > > > > -m memory size is default 64MB.
> > > > >
> > > > > Calculation:
> > > > > -> Calculated total pages used from stats
> slabs output parameter total_pages = 64 (If page size is 4MB then total
> pages
> > should not
> > > be more
> > > > than 16. Also
> > > > > when I store 8 items of ~3MB it uses 25 pages
> but if page size is 4MB, it should use 8 pages right.)
> > > > >
> > > > > Can you please help me in understanding the
> behaviour?
> > > > >
> > > > > Attached files with details for output of
> command stats settings and stats slabs.
> > > > > Below is the summarized view of the
> distribution.
> > > > > First added items with variable sizes, then
> then added items with 3MB and above.
> > > > >
> > > > > data_distribution.png
> > > > >
> > > > >
> > > > >
> > > > > Please let me know in case more details are
> required or question is not clear.
> > > > >
> > > > > Thank You,
> > > > > Shweta
> > > > >
> > > > > --
> > > > >
> > > > > ---
> > > > > 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].
> > > > > To view this discussion on the web visit
> > > >
> https://groups.google.com/d/msgid/memcached/2b640e1f-9f59-4432-a930-d830cbe8566do%40googlegroups.com.
> > > > >
> > > > >
> > > >
> > > > --
> > > >
> > > > ---
> > > > 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].
> > > > To view this discussion on the web visit
> > >
> https://groups.google.com/d/msgid/memcached/586aad58-c6fb-4ed8-89ce-6b005d59ba12o%40googlegroups.com.
> > > >
> > > >
> > >
> > > prod_stats.png
> > >
> > > --
> > >
> > > ---
> > > 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].
> > > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/memcached/8d011c1a-deec-463f-a17e-4e9908d97bdfo%40googlegroups.com.
> > >
> > >
> >
> > --
> >
> > ---
> > 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].
> > To view this discussion on the web visit
>
> https://groups.google.com/d/msgid/memcached/f0c2bfe1-d65d-4b62-9a87-68fc42446c3do%40googlegroups.com.
> >
> >
>
> --
>
> ---
> 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].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/memcached/bcd4da5a-ae8e-470f-beb9-2705c0f0202ao%40googlegroups.com.
>
>
--
---
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].
To view this discussion on the web visit
https://groups.google.com/d/msgid/memcached/alpine.DEB.2.21.2007041240450.18887%40dskull.
