For review: Stats slabs should include the number of requested bytes
Trond Norbye
It should be possible to detect the number of bytes actually allocated in a
given slab class to make it easier to detect if one is using the wrong
growth factor.
Patch: http://github.com/trondn/memcached/tree/issue_42
The stats slabs output looks like:
set a 1 0 1
a
STORED
stats slabs
STAT 1:chunk_size 80
STAT 1:chunks_per_page 13107
STAT 1:total_pages 1
STAT 1:total_chunks 13107
STAT 1:used_chunks 1
STAT 1:free_chunks 0
STAT 1:free_chunks_end 13106
STAT 1:mem_requested 51
STAT 1:get_hits 0
STAT 1:cmd_set 1
STAT 1:delete_hits 0
STAT 1:incr_hits 0
STAT 1:decr_hits 0
STAT 1:cas_hits 0
STAT 1:cas_badval 0
STAT active_slabs 1
STAT total_malloced 1048560
END
quit
Cheers,
Trond
Eric Lambert
The text 'mem_requested' is a little unclear to me. May be we call it
"bytes_used_in_slab" .... but that's a bit wordy ....
Also I wonder if we should represent this value a little differently.
So the point of this is to expose wasted space in the slab, right? If we
just represent this as a raw number of bytes, its not immediately clear
that there is an issue ... I have to compare this value against the
chunks size and number of chunks used. Couldnt we instead represent this
as a ratio of bytes used to bytes available (bytes_used/used_chunks *
chunk_size) , thereby making it a bit clearer, at least to me :-), what
the significance of this number is.
For example, in your case, you have one entry that uses 51 bytes of an
80 byte chunk. If we represent this value as a ratio, the stats would
show that this slab config results in wasting ~38% of the available slab
space.
my $.02
Eric
dormando
reservation is to not convert it to a lossy calculated value... It's
useful to be able to write a monitor to watch the more exact ratios, or
graph exact sizes. Which you lose if you calculate down the information
too far.
That said ... I don't have any great alternative ideas offhand.
-Dormando
Eric Lambert
the stats. If we expect the stats to be mainly consumed by tools and
monitoring frameworks, then I agree that we should just generate raw
numbers, but if we expect people to be directly using the stats, then I
think there is some value in these calculated numbers, even though they
are less than precise. Should we split the difference and generate both
the raw number and the calculated ratio?
Eric
Dustin
On Apr 8, 8:54 pm, Eric Lambert <eric.d.lamb...@gmail.com> wrote:
> Fair point .... so this raises a question about who is the audience for
> the stats. If we expect the stats to be mainly consumed by tools and
> monitoring frameworks, then I agree that we should just generate raw
> numbers, but if we expect people to be directly using the stats, then I
> think there is some value in these calculated numbers, even though they
> are less than precise. Should we split the difference and generate both
> the raw number and the calculated ratio?
perfect sense here.
1) Find out how much memory is in use, and how much is actually
required *right now*.
2) Trend the data over time.
Two variables increment -- only one decrements.
(sounds better if you say it with your dramatic voice)
Eric Bergen
Eric Bergen
eric....@provenscaling.com
http://www.provenscaling.com
Dustin
On Apr 9, 10:21 am, Eric Bergen <eric.ber...@gmail.com> wrote:
> Trending the data over time is better left to other tools that trend data
> over time. The memcached stats should be a snapshot in time that other tools
> can consume. If you start trending things in memcached you not only waste
> resources but you will end up with metrics like unix load average that are
> meaningless because they can't be directly compared to anything else.
a ``current'' value (e.g. how many clients are currently connected to
my server) vs. ``rate'' values (e.g. how many connections have there
ever been, which can be trended).
You don't have to pick one.
You *could* just increment both adds and removes separately and
compute the point-in-time. If a size_t counter ever wraps, that
becomes...quite difficult, though.
Eric Lambert
'waste_rate', if anyone is interested