<div dir="ltr">Hi Jay,<div><br></div><div style>there are indeed downsides with this setting.</div><div style>The code currently uses connection pooling in a way that each subtransaction end up using a distinct connection from the pool. As we have nested transactions in multiple points in Neutron's code, this leads to a situation where you can exhaust your pool.</div>
<div style><br></div><div style>This issue is already addressed by openstack.common db session management. Neutron is moving to that too. The patch [1] is under review at the moment, and we hope to be able to merge it soon.</div>
<div style><br></div><div style>Another issue [2] has been reported which leads to connection exhaustion both at small and large scales, independently of whether db pooling is enabled. We are retriaging this issue after we've been informed that openstack.common db support (and reduction of db accesses from policy engine) did not solve the issue.</div>
<div style><br></div><div style>Further, some plugins which drive a 3rd party backend might incur other issues when db pooling is enabled. As DB pooling increases the level of concurrency, it might happen that short-lived queries to the backend are performed while another long running query is executing. This is usually not harmful, except in cases when the short-lived query alters the portion of the state of the backend which the long running query is retrieving. Such events are usually observed during the initial synchronization of the DHCP server, and have been significantly mitigated by recent improvements in this procedure.</div>
<div style><br></div><div style>Regards,</div><div style>Salvatore</div><div style><br></div><div style>[1] <a href="https://review.openstack.org/#/c/27265/">https://review.openstack.org/#/c/27265/</a><br></div><div style>
[2] <a href="https://bugs.launchpad.net/tripleo/+bug/1184484">https://bugs.launchpad.net/tripleo/+bug/1184484</a></div><div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 21 June 2013 20:44, Jay Buffington <span dir="ltr"><<a href="mailto:me@jaybuff.com" target="_blank">me@jaybuff.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>I'm moving a thread we had with some vmware guys to this list to make it public.</div><div><br></div><div>We had a problem with quantum deadlocking when it got several requests in quick</div>
<div>succession.  Aaron suggested we set sql_dbpool_enable = True.  We did and it</div>
<div>seemed to resolve our issue.</div><div><br></div><div>What are the downsides of turning on sql_dbpool_enable?  Should it be on by default?</div><div><br></div><div>Thanks,</div><div>Jay</div><div><br></div><div><br>
</div>
<div>>> We are currently experience the following problem in our environment:</div><div>>> issuing 5 'quantum port-create' commands in parallel effectively deadlocks quantum:</div><div>>></div><div>

>> $ for n in $(seq 5); do echo 'quantum --insecure port-create stage-net1'; done | parallel </div><div>>> An unknown exception occurred.</div><div>>> Request Failed: internal server error while processing your request.</div>

<div>>> An unexpected error occurred in the NVP Plugin:Unable to get logical switches</div><div> </div><div>On Jun 21, 2013, at 9:36 AM, Aaron Rosen <<a href="mailto:arosen@vmware.com" target="_blank">arosen@vmware.com</a>> wrote:</div>

<div>> We've encountered this issue as well. I'd try enabling:</div><div>> # Enable the use of eventlet's db_pool for MySQL. The flags sql_min_pool_size,</div><div>> # sql_max_pool_size and sql_idle_timeout are relevant only if this is enabled.</div>

<div>></div><div>> sql_dbpool_enable = True</div><div>></div><div>> in nvp.ini to see if that helps at all. In our internal cloud we removed the</div><div>> creations of the lports in nvp from the transaction. Salvatore is working on</div>

<div>> an async back-end to the plugin that will solve this and improve the plugin</div><div>> performance.</div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto: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></blockquote></div><br></div>