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 <[email protected]> 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 <[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. > > > > > -- --- 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.
