<div dir="ltr">Hi Clint,<div><br></div><div>Thank you for your input.</div><div><br></div><div>If I understand you correctly, the core cause seems to be internal to OpenStack? If that's true, I will create a bug report about this. I'm guessing Oslo would be the correct project to file the bug?</div>
<div><br></div><div>Thanks,</div><div>Joe</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 21, 2014 at 12:19 PM, Clint Byrum <span dir="ltr"><<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Joe Topjian's message of 2014-08-14 09:09:59 -0700:<br>
<div class="">> Hello,<br>
><br>
> I have an OpenStack cloud with two HA cloud controllers. Each controller<br>
> runs the standard controller components: glance, keystone, nova minus<br>
> compute and network, cinder, horizon, mysql, rabbitmq, and memcached.<br>
><br>
> Everything except memcached is accessed through haproxy and everything is<br>
> working great (well, rabbit can be finicky ... I might post about that if<br>
> it continues).<br>
><br>
> The problem I currently have is how to effectively work with memcached in<br>
> this environment. Since all components are load balanced, they need access<br>
> to the same memcached servers. That's solved by the ability to specify<br>
> multiple memcached servers in the various openstack config files.<br>
><br>
> But if I take a server down for maintenance, I notice a 2-3 second delay in<br>
> all requests. I've confirmed it's memcached by editing the list of<br>
> memcached servers in the config files and the delay goes away.<br>
<br>
</div>I've seen a few responses to this that show a _massive_ misunderstanding<br>
of how memcached is intended to work.<br>
<br>
Memcached should never need to be load balanced at the connection<br>
level. It has a consistent hash ring based on the keys to handle<br>
load balancing and failover. If you have 2 servers, and 1 is gone,<br>
the failover should happen automatically. This gets important when you<br>
have, say, 5 memcached servers as it means that given 1 failed server,<br>
you retain n-1 RAM for caching.<br>
<br>
What I suspect is happening is that we're not doing that right by<br>
either not keeping persistent connections, or retrying dead servers<br>
too aggressively.<br>
<br>
In fact, it looks like the default one used in oslo-incubator's<br>
'memorycache', the 'memcache' driver, will by default retry dead servers<br>
every 30 seconds, and wait 3 seconds for a timeout, which probably<br>
matches the behavior you see. None of the places I looked in Nova seem<br>
to allow passing in a different dead_retry or timeout. In my experience,<br>
you probably want something like dead_retry == 600, so only one slow<br>
operation every 10 minutes per process (so if you have 10 nova-api's<br>
running, that's 10 requests every 10 minutes).<br>
<br>
It is also possible that some of these objects are being re-created on<br>
every request, as is common if caching is implemented too deep inside<br>
"middleware" and not at the edges of a solution. I haven't dug deep<br>
enough in, but suffice to say, replicating and load balancing may be the<br>
cheaper solution to auditing the code and fixing it at this point.<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</div></div></blockquote></div><br></div>