This is what http://code.google.com/p/memcached/issues/detail?id=42 is
trying to address.
Cheers,
Trond
On Apr 29, 2009, at 5:05 PM, Nicholas Tang wrote:
I know. :)
What I'm trying to figure out is what the bytes/limit_maxbytes ratio
shows me - theoretical % used bytes if there was no wastage from
excess space allocation for each chunk?
Thanks,
Nicholas
On 4/29/09, Dustin <[email protected]> wrote:
Slabs are fixed size. If you have a 1 byte object to store, by
default, it's going to use 80 bytes of memory.
On Apr 29, 3:54 pm, ntang <[email protected]> wrote:
Ok, I've got a question on slabs vs. main stats...
So here's one of my servers:
[r...@cc12-5 ~]# telnet 10.50.9.90 11213
Trying 10.50.9.90...
Connected to cc90-9.web.nap.ccops.us (10.50.9.90).
Escape character is '^]'.
stats
STAT pid 24458
STAT uptime 694639
STAT time 1241044888
STAT version 1.2.8
STAT pointer_size 64
STAT rusage_user 63.251384
STAT rusage_system 146.914665
STAT curr_items 754674
STAT total_items 2309096
STAT bytes 1860697442
STAT curr_connections 1044
STAT total_connections 846349
STAT connection_structures 1772
STAT cmd_flush 0
STAT cmd_get 6623750
STAT cmd_set 2309076
STAT get_hits 4234984
STAT get_misses 2388766
STAT evictions 53109
STAT bytes_read 4224402099
STAT bytes_written 4002657189
STAT limit_maxbytes 2097152000
STAT threads 2
STAT accepting_conns 1
STAT listen_disabled_num 0
END
^]
telnet> quit
Connection closed.
If you compare bytes and limit_maxbytes, it looks like this
memcached
instance is 88.7% used.
But I wrote a quick script to grab the per-slab stats:
SERVER: 10.50.9.90:11213
SLAB SIZE #/page #PAGES #CHUNKS AVAIL ASPACE %USED
1 104 10082 15 151230 0 0 100.0%
2 136 7710 2 15420 0 0 100.0%
3 176 5957 6 35742 1 176 100.0%
4 224 4681 2 9362 4 896 100.0%
5 280 3744 1 3744 237 66360 93.7%
6 352 2978 48 142944 4 1408 100.0%
7 440 2383 23 54809 0 0 100.0%
8 552 1899 54 102546 1 552 100.0%
9 696 1506 18 27108 2 1392 100.0%
10 872 1202 46 55292 1 872 100.0%
11 1096 956 23 21988 0 0 100.0%
12 1376 762 20 15240 1 1376 100.0%
13 1720 609 62 37758 3 5160 100.0%
14 2152 487 14 6818 0 0 100.0%
15 2696 388 34 13192 0 0 100.0%
16 3376 310 18 5580 1 3376 100.0%
17 4224 248 3 744 59 249216 92.1%
18 5280 198 3 594 114 601920 80.8%
19 6600 158 2 316 35 231000 88.9%
20 8256 127 27 3429 0 0 100.0%
21 10320 101 59 5959 1 10320 100.0%
22 12904 81 145 11745 0 0 100.0%
23 16136 64 80 5120 2 32272 100.0%
24 20176 51 30 1530 0 0 100.0%
25 25224 41 16 656 0 0 100.0%
26 31536 33 19 627 0 0 100.0%
27 39424 26 240 6240 0 0 100.0%
28 49280 21 831 17451 0 0 100.0%
29 61600 17 20 340 0 0 100.0%
30 77000 13 30 390 0 0 100.0%
31 96256 10 56 560 0 0 100.0%
32 120320 8 84 672 0 0 100.0%
33 150400 6 1 6 5 752000 16.7%
TOTALS: 755152 471 1958296 99.9%
As you can see, it's a slightly different story. To see if it would
make a difference, I tried to figure out what the available space
from
those 480 chunks would be, and compared that to the limit_maxbytes,
and it still seemed to come out around that same 99.9% level of
utilization.
So is that 99.9% the accurate number I should be using for
utilization? (Or more accurately, should I calculate 1.) the total
size based on the total of (# chunks * size) for each slab, and
compare it to 2.) the total available space based on the total of
( avail chunks * size) for each slab?)
And if that's accurate, is the rest of the space lost to the slab
allocation and overhead?
Now I'm debating if I should update memcache-top to report on actual
available space based on the slab stats, since that's a very
different
number from the available space according to bytes vs.
limit_maxbytes... :)
Thanks,
Nicholas
--
Sent from my mobile device
--
Trond Norbye
Application Platform Software Group E-mail: [email protected]
SUN Microsystems Phone: +47 73842100
Haakon VII's gt. 7B Fax: +47 73842101
7485 Trondheim, Norway
