Patch: Dynamic hashtable sizing

[Timo Ewalds]

Steven Grimm wrote:
> The average size of a data item can vary dramatically between 
> memcached instances if you're using separate pools for different kinds 
> of data, which means the optimal number of hash buckets isn't simply a 
> function of max memory usage. In one of our pools, each data item is 
> exactly 4 bytes; in another, the average size is several kilobytes. So 
> at the very least there needs to be some kind of tuning parameter to 
> control the expected average value size.
Given the average size and the max amount of space once you first decide 
to resize, can you make it only need to resize the hash once or twice 
instead of several times? If your average size is 4 bytes and max memory 
is 15gb, you can figure out that you're likely going to need alot more 
hash space than just double, so while the cache is still small, make the 
hash 16 times as big the first time instead of having to double it 4 
times (or whatever).

> With dynamic resizing, we can assign any memcached instance to any 
> pool as needed and it just works. (In fact, we're working on a 
> failover system that assigns a hot-spare memcached instance to replace 
> a failed node automatically.) With static sizing, even with a tuning 
> parameter, we have to go mess with the settings on each memcached 
> instance based on which pool we expect to assign it to.
I can't wait to see how you do the failover with a hot spare. We've been 
thinking along the same lines

Timo