Mike,

> Werner you never mentioned which version of memcache you're using. For
> what it's worth, it seems things differ between 1.4.0 and 1.2.6.
> (Haven't peeked at 1.3.x series.)

Sorry. I started this before 1.4 has been out, and as we are running
in
production environment, we are using 1.2.6 and not 1.3.
1.4 is not stable in gentoo portage by now, but I guess it would make
no real difference (see below)

> 1.2.6 will allocate a new slab if memory is available, before grabbing
> the last item off the free list (which may or may not have expired.)

seems so :)

> 1.4.0 will look for an expired object off the free list (last 50
> items), before performing the above allocate-then-evict logic.

Trond explained this some days ago.
But this does not help either very much. It is just another default
breaking point.

We do use different cache times for differend kind of objects
 (e.g. articles, that are usually not changed that often get
a lifetime for up to 30 days, while sessions get a lifetime hours.

As there are many articles (up to 1.5 Mio), it is quite likely
the old articles out of the archive are not read  that often and
thus tend to be located at the end of the chain. And, also quite
likely,
there will be more than 50 Objects, maybe not at start, but at least
after picking some of the expired events out of that range.
So we will end the same. just maybe later.

> Your other option is to compile with ALLOW_SLABS_REASSIGN and then

I tried that already, but I don't want to compile manually in our
production environnment and V1.2.6 does
not compile with gcc-4.x. See my filed issue about that.
http://code.google.com/p/memcached/issues/detail?id=47

> right a cron/daemon which uses the memcache evicts and maxage stats to
> attempt to dynamically rebalance the pool, automating the
> one-at-a-time "slabs reassign" behavior to make it more effective.

yes, but then it may be to late as there might already be items
evicted.
And you can only evict one page at a time. We don't have memcache-
servers
with 64 MB, but more likely with 4096 MB, so reassigning one or two
pages
would be just a small benefit.

btw: my expire Script runs quite nicely. I Put some examples from our
newly rrd graphs here: http://www.maiers.de/memcache/

so with my script I don't get to the point where no allocatable memory
is left, and so I have the solutions for my problem. but it is
still the wrong way to expire from the client, as I mentioned before.

The first two are just expired but not restartet yet.
the third one is after a fresh memcached-restart.
as you can see, the allocated #pages grows slowly but tends to
be below 400 MB on that server.
(allocated ist just the sum of all 1-mb-pages that are listed
with memcached-tool, so allocated could be higher than max, as
9 M of RAM could leed to 10 pages of 300k blocks, default behaviour
without ALLOW_SLABS_REASSIGN).

the script just runs every 30 minutes and that seems to be enough for
most cases.

regards.

Werner.

Reply via email to