On 12/20/08 4:42 AM, Toru Maesaka tmaes...@gmail.com wrote:
Hi!
I've quickly glanced through the repo and even though I think the idea
of the flat allocator is neat and how it uses mmap (/me loves mmap), I
think the flat allocator itself should belong outside the codebase.
So, what I'm trying to
Hi!
I've quickly glanced through the repo and even though I think the idea
of the flat allocator is neat and how it uses mmap (/me loves mmap), I
think the flat allocator itself should belong outside the codebase.
So, what I'm trying to say is, shouldn't this be a separate storage
engine?
Trond
Toru Maesaka wrote:
oops, clicked send before I finished the email :(
ASFAIK, Trond and Matt has been experimenting quite a bit with what
I've mentioned above.
True, more Trond than I. I've been working on a method of testing, and
have a good workload generator. We're actually not
I re-did facebook-memcached to make it consistent with dustin's github
repository. (No more src subdirectory, and I redid the commit
history so that it appears to be a branch from the original 1.2.3
release at
http://github.com/dustin/memcached/commit/437beab948aec088dac361f27c89f3619fee3228
)
On Dec 19, 3:27 am, marc kwiatkowski marc.kwiatkow...@gmail.com
wrote:
I re-did facebook-memcached to make it consistent with dustin's github
repository. (No more src subdirectory, and I redid the commit
history so that it appears to be a branch from the original 1.2.3
release at
On Dec 19, 9:17 am, Josh Snyder j...@admob.com wrote:
First, we wanted to solve the slab-ghetto problem. That is the
situation where one slab is forcing out hot keys for lack of memory
while another slab holds onto stale objects.
Just wanted to give a +1 that this is an issue for others
Well, there's #3 - rebalance the existing slabs using the slab
reassignment command that nobody knows about. :)
Do tell! :)
On the protocol side: It'd be great to get it added to
http://code.sixapart.com/svn/memcached/trunk/server/doc/protocol.txt
and eventually to the various client
