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?
Eric
dormando wrote:
I second the idea of making the value a little more clear/useful. My only
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
On Wed, 8 Apr 2009, Eric Lambert wrote:
Looks fine to me. Although perhaps we could use a better description. 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
Trond Norbye wrote:
Issue: http://code.google.com/p/memcached/issues/detail?id=42
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
