If you want? What would make you confident enough to try the branch in production? Or do you rely on your other patches and that's not really possible?
On Thu, 15 Jan 2015, Zhiwei Chan wrote: > I try to use real traffic of application to make a compare test, but it > seems that not all of guys use the cache-client with consistent hash in > dev environment. The result is that the traffic is not distributed well as I > supposed. > Should I fake the traffic and make a compare test instead of real traffic? > e.g., fake the random expire-time keys traffic to set and get for > memcached. > > --------------- > host mc56 installs the most update LRU-rework branch's memcached with option > likes "/usr/local/bin/memcached -u nobody -d -c 10240 -o > lru_maintainer lru_crawler -m 64 -p 11811"; > host mc57 install the version 1.4.20_7_gb118a6c's memcached, with option > likes "/usr/bin/memcached -u nobody -d -c 10240 -o tail_repair_time=7200 > -m 64 -p 11811", > > I sum up the stats of all memcache instances on the host and make followings > analysis: > > Inline image 1 > > On Wed, Jan 14, 2015 at 1:58 AM, dormando <dorma...@rydia.net> wrote: > Last update to the branch was 3 days ago. I'm not planning on doing any > more work on it at the moment, so people have a chance to test it. > > thanks! > > On Tue, 13 Jan 2015, Zhiwei Chan wrote: > > > I compile directly using your branch on the test server, and please > tell me if it need update and re-compile. > > > > On Tue, Jan 13, 2015 at 4:20 AM, dormando <dorma...@rydia.net> wrote: > > That sounds like an okay place to start. Can you please make > sure the > > other dev server is running the very latest version of the > branch? A lot > > changed since last friday... a few pretty bad bugs. > > > > Please use the startup options described in the middle of the > PR. > > > > If anyone's brave enough to try the latest branch on one > production > > instance (if they have a low traffic one somewhere, maybe?) > that'd be > > good. I ran the branch under a load tester for a few hours, it > passes > > tests, etc. If I merge it, it'll just go into people's > productions without > > ever having a production test first, so hopefully someone can > try it? > > > > thanks > > > > On Mon, 12 Jan 2015, Zhiwei Chan wrote: > > > > > I have run it since last Friday, so far no crash. As I have > finished the haproxy works today, I will try a compare test for > this > > LRU works > > > tomorrow as following: There are two servers(Centos 5.8, > 8cores, 8G memory) in the dev environment, Both of server run 32 > > memcached > > > instances(processes) with maxmum memory of 128M. One server > runs version 1.4.21, the other runs this branch. There are lots > of > > "pools" using these > > > memcached server, and all of pools use tow memcached > instances on different server. The client of pools use Consistent Hash > algorithm > > to distribute > > > keys to their 2 memcached instances. I will watch the > hit-rate and other performance using Cacti. > > > I think it will work, but usually there is not much traffic > in our dev environment. Please tell me if any other advice. > > > > > > > > > 2015-01-08 4:21 GMT+08:00 dormando <dorma...@rydia.net>: > > > Hey, > > > > > > To all three of you: Just run it anywhere you can (but > not more than one > > > machine, yet?), with the options prescribed in the PR. > Ideally you have > > > graphs of the hit ratio and maybe cache fullness and > can compare > > > before/after. > > > > > > And let me know if it hangs or crashes, obviously. If > so a backtrace > > > and/or coredump would be fantastic. > > > > > > On Thu, 8 Jan 2015, Zhiwei Chan wrote: > > > > > > > I will deploy it to one of our test environment on > CentOS 5.8, for a comparison test with the 1.4.21, although the > > workloads is > > > not as heavy as > > > > product environment. Tell me if any I could help. > > > > > > > > 2015-01-07 23:30 GMT+08:00 Eric McConville > <erichasem...@gmail.com>: > > > > Same here. Do you want any findings posted to > the mailing list, or the PU thread? > > > > > > > > On Wed, Jan 7, 2015 at 5:56 AM, Ryan McCullagh > <m...@ryanmccullagh.com> wrote: > > > > I'm willing to help out in any way possible. > What can I do? > > > > > > > > -----Original Message----- > > > > From: memcached@googlegroups.com > [mailto:memcached@googlegroups.com] On > > > > Behalf Of dormando > > > > Sent: Wednesday, January 7, 2015 3:52 AM > > > > To: memcached@googlegroups.com > > > > Subject: memory efficiency / LRU refactor branch > > > > > > > > Yo, > > > > > > > > https://github.com/memcached/memcached/pull/97 > > > > > > > > Opening to a wider audience. I need some folks > willing to poke at it and see > > > > if their workloads fair better or worse with > respect to hit ratios. > > > > > > > > The rest of the work remaining on my end is > more testing, and some TODO's > > > > noted in the PR. The remaining work is > relatively small aside from the page > > > > mover idea. It hasn't been crashing or hanging > in my testing so far, but > > > > that might still happen. > > > > > > > > I can't/won't merge this until I get some > evidence that it's useful. > > > > Hoping someone out there can lend a hand. I > don't know what the actual > > > > impact would be, but for some workloads it > could be large. Even for folks > > > > who have set all items to never expire, it > could still potentially improve > > > > hit ratios by better protecting active items. > > > > > > > > It will work best if you at least have a mix of > items with TTL's that expire > > > > in reasonable amounts of time. > > > > > > > > thanks, > > > > -Dormando > > > > > > > > -- > > > > > > > > --- > > > > You received this message because you are subscribed > to the Google Groups "memcached" group. > > > > To unsubscribe from this group and stop receiving > emails from it, send an email to > memcached+unsubscr...@googlegroups.com. > > > > For more options, visit > https://groups.google.com/d/optout. > > > > > > > > > > > > -- > > > > > > > > --- > > > > You received this message because you are subscribed > to the Google Groups "memcached" group. > > > > To unsubscribe from this group and stop receiving > emails from it, send an email to > memcached+unsubscr...@googlegroups.com. > > > > For more options, visit > https://groups.google.com/d/optout. > > > > > > > > > > > > -- > > > > > > > > --- > > > > You received this message because you are subscribed > to the Google Groups "memcached" group. > > > > To unsubscribe from this group and stop receiving > emails from it, send an email to > memcached+unsubscr...@googlegroups.com. > > > > For more options, visit > https://groups.google.com/d/optout. > > > > > > > > > > > > > > > > > -- > > > > > > --- > > > You received this message because you are subscribed to the > Google Groups "memcached" group. > > > To unsubscribe from this group and stop receiving emails from > it, send an email to memcached+unsubscr...@googlegroups.com. > > > For more options, visit https://groups.google.com/d/optout. > > > > > > > > > > > > -- > > > > --- > > You received this message because you are subscribed to the Google > Groups "memcached" group. > > To unsubscribe from this group and stop receiving emails from it, > send an email to memcached+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > > > > > > > -- > > --- > You received this message because you are subscribed to the Google Groups > "memcached" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to memcached+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > >
