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 <[email protected]>: > 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 <[email protected]>: > > 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 > <[email protected]> wrote: > > I'm willing to help out in any way possible. What can I do? > > > > -----Original Message----- > > From: [email protected] > [mailto:[email protected]] On > > Behalf Of dormando > > Sent: Wednesday, January 7, 2015 3:52 AM > > To: [email protected] > > 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 [email protected]. > > 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 [email protected]. > > 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 [email protected]. > > 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 [email protected]. > For more options, visit https://groups.google.com/d/optout. > >
