Well, I beg to differ.
We used to have evictions > 0, actually around 200 (per whatever munin
counts them), so we used to think, that we have too small number of
machines, and kept adding them.
After using the patch, the memory usage dropped by 80%, and we have no
evictions since a long time, which means, that evictions where misleading,
and happened just because LRU sometimes kills fresh items, even though there
are lots of outdated keys.

Moreover it's not like RAM usage "fluctuates wildly". It's kind of constant,
or at least periodic, so you can very accurately say if something bad
happened, as it would be instantly visible as a deviation from yesterday's
charts. Before applying the patch, you could as well not look at the chart
at all, as it was more than sure that it always shows 100% usage, which in
my opinion gives no clue about what is actually going on.

Even if you are afraid of "wildly fluctuating" charts, you will not solve
the problem by hiding it, and this is what actually happens if you don't
have GC -- the traffic, the number of outdated keys, they all fluctuate, but
you just don't see it, if the chart always shows 100% usage...

2010/7/22 Brian Moon <[email protected]>

> On 7/22/10 5:46 AM, Jakub Łopuszański wrote:
>
>> I see that my patch for garbage collection is still being ignored, and
>> your post gives me some idea about why it is so.
>> I think that RAM is a real problem, because currently (without GC) you
>> have no clue about how much RAM you really need. So you can end up
>> blindly buying more and more machines, which effectively means that
>> multiget works worse and worse (client issues one big multiget but it
>> gets split into many packets to many servers).
>> Currently we try to get number of servers in the cluster smaller based
>> on the reall consumption to get more from multiget feature.
>>
>
> I would never, never, never want my memcached daemon ram usage to fluctuate
> wildly. Eviction rate is a much better determination of how well your cache
> is being used.
>
> --
>
> Brian.
> --------
> http://brian.moonspot.net/
>

Reply via email to