<div dir="ltr">Hi,<div><br></div><div>There are two main patches that I am interested in back-porting to improve the performance of the DB queries issued frequently by L2 agents while they are hosting VMs. These are not one-time queries during specific operations (e.g. create/delete), they also happen during normal periodic checks from the L2 agent. Due this constant background behavior, the agents start to trample the Neutron server once the deployment size scales up and will eventually exceed its resources so it can no longer service API requests even though nothing is changing.</div><div><br></div><div>The only work-around for this right now is to abnormally scale (compared to any of the other standard OpenStack services) the Neutron server and the MySQL nodes to handle the query load. This is really discouraging to deployers (lots of extra compute power wasted as service nodes) and makes Neutron appear extremely unstable to deployers who do not know Neutron needs to be special-cased in this manner.</div><div><br></div><div>The first patch is to batch up the ports being requested from an RPC agent before querying the database.[1] This is an internal-only change (doesn't affect the data delivered to RCP callers). Before, the server was calling the DB for each port individually so a query from a high-density port node like an L3 agent could result in 1000+ DB queries to the database. Now the service will query the database for all of the port information at once and then group it by port like the agents expect. This is probably the most significant improvement when dealing with high-density nodes and there is a rally performance graph demonstrating this in the comments.</div><div><br></div><div>The second patch is to eliminate a join across the Neutron port table that was a completely unnecessary calculation for the DB to perform and a waste of data returned (every column from every table in the query).[2] This also doesn't change the data returned to the caller of the function (no missing dict entries, etc), so we shouldn't have to worry about out-of-tree drivers, tools, etc. being broken by this either. I will run the rally performance numbers for this one as well after the first patch gets merged since it has a higher impact than this one.</div><div><br></div><div>Let me know if I need to elaborate on anything.</div><div><br></div><div>1. <a href="https://review.openstack.org/#/c/132372/">https://review.openstack.org/#/c/132372/</a></div><div>2. <a href="https://review.openstack.org/#/c/130101/">https://review.openstack.org/#/c/130101/</a></div><div><br></div><div>Thanks,</div><div>Kevin Benton</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 29, 2014 at 6:09 AM, Ihar Hrachyshka <span dir="ltr"><<a href="mailto:ihrachys@redhat.com" target="_blank">ihrachys@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA512<br>
<br>
On 29/10/14 14:00, Dolph Mathews wrote:<br>
><br>
> On Wed, Oct 29, 2014 at 5:23 AM, Ihar Hrachyshka<br>
> <<a href="mailto:ihrachys@redhat.com">ihrachys@redhat.com</a> <mailto:<a href="mailto:ihrachys@redhat.com">ihrachys@redhat.com</a>>> wrote:<br>
><br>
> Hi all,<br>
><br>
> there is a series of Neutron backports in the Juno queue that are<br>
> intended to significantly improve service performance when<br>
> handling security groups (one of the issues that are main pain<br>
> points of current users):<br>
><br>
> - <a href="https://review.openstack.org/130101" target="_blank">https://review.openstack.org/130101</a> -<br>
> <a href="https://review.openstack.org/130098" target="_blank">https://review.openstack.org/130098</a> -<br>
> <a href="https://review.openstack.org/130100" target="_blank">https://review.openstack.org/130100</a> -<br>
> <a href="https://review.openstack.org/130097" target="_blank">https://review.openstack.org/130097</a> -<br>
> <a href="https://review.openstack.org/130105" target="_blank">https://review.openstack.org/130105</a><br>
><br>
> The first four patches are optimizing db side (controller), while<br>
> the last one is to avoid fetching security group rules by OVS agent<br>
> when firewall is disabled.<br>
><br>
> AFAIK we don't generally backport performance improvements unless<br>
> they are very significant (though I don't see anything written in<br>
> stone that says so), but knowing that those patches fix pain<br>
> hotspots in Neutron, and seem rather isolated, should we consider<br>
> their inclusion?<br>
><br>
> Should we come up with some "official" rule on how we handle<br>
> performance enhancement backports?<br>
><br>
><br>
>> I'm very much in favor of backporting known performance<br>
>> improvements, but in my experience, not all "performance<br>
>> improvements" actually improve performance, so I'd expect an<br>
>> appropriate benchmark to demonstrate a real performance benefit<br>
>> to coincide with the proposed patch.<br>
<br>
Exactly. That's what I asked to elaborate on at:<br>
<a href="https://review.openstack.org/#/c/130101/" target="_blank">https://review.openstack.org/#/c/130101/</a><br>
<br>
Also, adding Kevin into CC to make sure he is aware of the discussion.<br>
<br>
><br>
>> For a hypothetical example, what seems like a clear cut<br>
>> improvement in review 130098 (remove unused columns from a query)<br>
>> *might* have an unforeseen side effect later on, where another<br>
>> component doesn't have the data it needs, so it suddenly starts<br>
>> issuing a new DB query to compensate. OpenStack is certainly<br>
>> complicated enough that it's impossible to make accurate<br>
>> assumptions about performance.<br>
><br>
><br>
><br>
> /Ihar<br>
><br>
> _______________________________________________<br>
> Openstack-stable-maint mailing list<br>
> <a href="mailto:Openstack-stable-maint@lists.openstack.org">Openstack-stable-maint@lists.openstack.org</a><br>
> <mailto:<a href="mailto:Openstack-stable-maint@lists.openstack.org">Openstack-stable-maint@lists.openstack.org</a>><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint</a><br>
><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Openstack-stable-maint mailing list<br>
> <a href="mailto:Openstack-stable-maint@lists.openstack.org">Openstack-stable-maint@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint</a><br>
><br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)<br>
<br>
iQEcBAEBCgAGBQJUUObtAAoJEC5aWaUY1u57UYwH/j+wjiydOXjA+lFi3l1Pbl5f<br>
s7r4Ox6FCPPVoAKziKpygKRbHTrCTew4DcgOxZhmC9qoq+Rk8Q1WFMLlBQ+51Kjj<br>
lj/72JiPenKvuZSl/E+9FsmWP7ReCCyUMYWiQS6wp6FAd5KpQMMgdjleUQWEAgjN<br>
Y1M9kYVOmqnYHQy4oWJsV0Od2wFKFAGDKohLEzDocmTQFxcfkEeMSn3qJ4aOwkoz<br>
KmTFKPGAGU8eTyYNAs3sHa0t9VFwvPoBg4EjMXBjkuoRxz+Nf/IPUZmrruXQ7LM6<br>
ioXEUH3GdKQSCKWtYoFFI1QPpiTQSIalO6nURxUg0UldW6i5QwIX1LTz8GMG+TQ=<br>
=JJq0<br>
-----END PGP SIGNATURE-----<br>
</blockquote></div><br></div><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div>Kevin Benton</div></div>