Re: Using PCIe SSDs instead of RAM
On Fri, Jul 23, 2010 at 8:47 AM, dormando wrote: > I tried. > > Try the engine branch? > > I guess, I'll have to at some point. Just wanted to say, that LRU was designed as an algorithm for a uniform cost model, where all elements are almost equally important (have the same cost of miss) and the only thing that distinguishes them is the pattern of accesses. This is clearly not a good model for memcache, where: some elements are totally unimportant as they have already expired, some elements are larger than the others, some are always processed in batches (multigets), and so on. In my opinion GC moves the reality closer to the model, by removing unimportant elements, so if you want LRU to work correctly you should at least perform GC. You could also try to modify LRU to model that one large item actually occupies space that could be better utilies by several small elements (this is also a simple change). If you fill comfortable without GC, I am OK with that, just do not suggest, that GC is against LRU.
Re: Issue 122 in memcached: failed to write, and not due blocking: No error
That client library is old and hasn't been under active development for years. Have you tried with a better client such as http://code.google.com/p/beitmemcached/ or Enyim? I have a vague memory of getting that error when the client didn't handle some commands correctly. /Henrik On Fri, Jul 23, 2010 at 01:28, wrote: > > Comment #1 on issue 122 by billyle...@suddenlink.net: failed to write, and > not due blocking: No error > > http://code.google.com/p/memcached/issues/detail?id=122 > > I have just installed win32-1.4.4-54 server along with > memcacheddotnet_clientlib-1.1.5 and am getting 'Failed to write, and not due > to blocking: No error' every time my client calls the server(Get, Set, > Stats, i.e.). I have tried tweaking the command line args with no success. > Any ideas. I've run memcached on linux for years without any type of > problems but as usual there is probably an issue with something in windoze7. > > thx. > >
Re: Using PCIe SSDs instead of RAM
There are alternatives to LRU, which is generally chosen for being extremely simple to implement, fast, and has a reasonable hit rate. The Greedy-Dual-Size-Frequency policy may be more appropriate for memcached as it accounts a value's weight. I doubt that there's a lot of value of changing the current design, but there are alternatives to approaches that would need to be considered if GC was a serious consideration. From: Jakub Łopuszański To: memcached@googlegroups.com Sent: Fri, July 23, 2010 12:16:16 AM Subject: Re: Using PCIe SSDs instead of RAM On Fri, Jul 23, 2010 at 8:47 AM, dormando wrote: I tried. > >Try the engine branch? > > > I guess, I'll have to at some point. Just wanted to say, that LRU was designed as an algorithm for a uniform cost model, where all elements are almost equally important (have the same cost of miss) and the only thing that distinguishes them is the pattern of accesses. This is clearly not a good model for memcache, where: some elements are totally unimportant as they have already expired, some elements are larger than the others, some are always processed in batches (multigets), and so on. In my opinion GC moves the reality closer to the model, by removing unimportant elements, so if you want LRU to work correctly you should at least perform GC. You could also try to modify LRU to model that one large item actually occupies space that could be better utilies by several small elements (this is also a simple change). If you fill comfortable without GC, I am OK with that, just do not suggest, that GC is against LRU.
Re: Using PCIe SSDs instead of RAM
On Jul 23, 11:31 am, Ben Manes wrote: > There are alternatives to LRU, which is generally chosen for being extremely > simple to implement, fast, and has a reasonable hit rate. The > Greedy-Dual-Size-Frequency policy may be more appropriate for memcached as it > accounts a value's weight. I doubt that there's a lot of value of changing the > current design, but there are alternatives to approaches that would need to be > considered if GC was a serious consideration. An engine that does this would be welcome. :) A big reason storage engines were introduced a while back was so that people with different theories of operation could could implement new storage or eviction models and have them maintain relevance as the memcached core itself progresses forward. There's nobody to say you can't have your own engine for people to try out (and perhaps even have excellent luck in different environments), and if/when a universally better model arises, we can change defaults.
