Clark Boylan <<a href="mailto:cboylan@sapwetik.org">cboylan@sapwetik.org</a>> Wrotr :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Sep 17, 2014, at 06:48 PM, Clark Boylan wrote:<br>
> On Wed, Sep 17, 2014, at 06:37 PM, Matt Riedemann wrote:<br>
> ><br>
> ><br>
> > On 9/17/2014 7:59 PM, Ian Wienand wrote:<br>
> > > On 09/18/2014 09:49 AM, Clark Boylan wrote:<br>
> > >> Recent sampling of test run times shows that our tempest jobs run<br>
> > >> against clouds using PostgreSQL are significantly slower than jobs run<br>
> > >> against clouds using MySQL.<br>
> > ><br>
> > > FYI There is a possibly relevant review out for max_connections limits<br>
> > > [1], although it seems to have some issues with shmem usage<br>
> > ><br>
> > > -i<br>
> > ><br>
> > > [1] <a href="https://review.openstack.org/#/c/121952/" target="_blank">https://review.openstack.org/#/c/121952/</a><br>
> > ><br>
> > > _______________________________________________<br>
> > > OpenStack-dev mailing list<br>
> > > <a href="javascript:;" onclick="_e(event, 'cvml', 'OpenStack-dev@lists.openstack.org')">OpenStack-dev@lists.openstack.org</a><br>
> > > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> > ><br>
> ><br>
> > That's a backport of a fix from master where we were hitting fatal<br>
> > errors due to too many DB connections which was brought on by the<br>
> > changes to cinder and glance to run as many workers as there were CPUs<br>
> > available.  So I don't think it probably plays here...<br>
> ><br>
> > The errors pointed out in another part of the thread have been around<br>
> > for awhile, I think they are due to negative tests where we're hitting<br>
> > unique constraints because of the negative tests, so they are expected.<br>
> ><br>
> > We should also note that the postgresql jobs run with the nova metadata<br>
> > API service, I'm not sure how much of a factor that would have here.<br>
> ><br>
> > Is there anything else unique about those jobs from the MySQL ones?<br>
> ><br>
> Good question. There are apparently other differences. The postgres job<br>
> runs Keystone under eventlet instead of via apache mod_wsgi. It also<br>
> sets FORCE_CONFIGDRIVE=False instead of always. And the final difference<br>
> I can find is the one you point out, nova api metadata service is run as<br>
> an independent thing.<br>
><br>
> Could these things be related? It would be relatively simple to push a<br>
> change or two to devstack-gate to test this but there are enough options<br>
> here that I probably won't do that until we think at least one of these<br>
> options is at fault.<br>
I am starting to feel bad that I picked on PostgreSQL and completely<br>
forgot that there were other items in play here. I went ahead and<br>
uploaded [0] to run all devstack jobs without keystone wsgi services<br>
(eventlet) and [1] to run all devstack job with keystone wsgi services<br>
and the initial results are pretty telling.<br>
<br>
It appears that keystone eventlet is the source of the slowness in this<br>
job. With keystone eventlet all of the devstack jobs are slower and with<br>
keystone wsgi all of the jobs are quicker. Probably need to collect a<br>
bit more data but this doesn't look good for keystone eventlet.<br>
<br>
Thank you Matt for pointing me in this direction.<br>
<br>
[0] <a href="https://review.openstack.org/#/c/122299/" target="_blank">https://review.openstack.org/#/c/122299/</a><br>
[1] <a href="https://review.openstack.org/#/c/122300/" target="_blank">https://review.openstack.org/#/c/122300/</a><br>
> ><br>
> > --<br>
> ><br>
> > Thanks,<br>
> ><br>
> > Matt Riedemann<br>
> ><br>
</blockquote><div><br></div><div>I've kicked off a test[1] as well to check into some tunable options (eventlet workers) for improving keystone eventlet performance. I'll circle back with the infra team once we have a little more data on both fronts. The Keystone team will use this data to figure out the best way to approach this issue. </div><div><br></div><div>--Morgan<span></span></div><div><br></div><div>[1] <a href="https://review.openstack.org/#/c/122308/">https://review.openstack.org/#/c/122308/</a></div><br>