<p dir="ltr"><br>
On Jul 11, 2014 5:32 PM, "Vishvananda Ishaya" <<a href="mailto:vishvananda@gmail.com">vishvananda@gmail.com</a>> wrote:<br>
><br>
> I have tried using pymysql in place of mysqldb and in real world concurrency<br>
> tests against cinder and nova it performs slower. I was inspired by the mention<br>
> of mysql-connector so I just tried that option instead. Mysql-connector seems<br>
> to be slightly slower as well, which leads me to believe that the blocking inside of</p>
<p dir="ltr">Do you have some numbers?  "Seems to be slightly slower" doesn't really stand up as an argument against the numbers that have been posted in this thread.  </p>
<p dir="ltr">> sqlalchemy is not the main bottleneck across projects.<br>
><br>
> Vish<br>
><br>
> P.S. The performanace in all cases was abysmal, so performance work definitely<br>
> needs to be done, but just the guess that replacing our mysql library is going to<br>
> solve all of our performance problems appears to be incorrect at first blush.</p>
<p dir="ltr">The motivation is still mostly deadlock relief but more performance work should be done.  I agree with you there.  I'm still hopeful for some improvement from this.</p>
<p dir="ltr">><br>
> On Jul 11, 2014, at 10:20 AM, Clark Boylan <<a href="mailto:clark.boylan@gmail.com">clark.boylan@gmail.com</a>> wrote:<br>
><br>
> > Before we get too far ahead of ourselves mysql-connector is not hosted<br>
> > on pypi. Instead it is an external package link. We recently managed<br>
> > to remove all packages that are hosted as external package links from<br>
> > openstack and will not add new ones in. Before we can use<br>
> > mysql-connector in the gate oracle will need to publish<br>
> > mysql-connector on pypi properly.<br>
> ><br>
> > That said there is at least one other pure python alternative,<br>
> > PyMySQL. PyMySQL supports py3k and pypy. We should look at using<br>
> > PyMySQL instead if we want to start with a reasonable path to getting<br>
> > this in the gate.<br>
> ><br>
> > Clark<br>
> ><br>
> > On Fri, Jul 11, 2014 at 10:07 AM, Miguel Angel Ajo Pelayo<br>
> > <<a href="mailto:mangelajo@redhat.com">mangelajo@redhat.com</a>> wrote:<br>
> >> +1 here too,<br>
> >><br>
> >> Amazed with the performance gains, x2.4 seems a lot,<br>
> >> and we'd get rid of deadlocks.<br>
> >><br>
> >><br>
> >><br>
> >> ----- Original Message -----<br>
> >>> +1<br>
> >>><br>
> >>> I'm pretty excited about the possibilities here.  I've had this<br>
> >>> mysqldb/eventlet contention in the back of my mind for some time now.<br>
> >>> I'm glad to see some work being done in this area.<br>
> >>><br>
> >>> Carl<br>
> >>><br>
> >>> On Fri, Jul 11, 2014 at 7:04 AM, Ihar Hrachyshka <<a href="mailto:ihrachys@redhat.com">ihrachys@redhat.com</a>> wrote:<br>
> >>>> -----BEGIN PGP SIGNED MESSAGE-----<br>
> >>>> Hash: SHA512<br>
> >>>><br>
> >>>> On 09/07/14 13:17, Ihar Hrachyshka wrote:<br>
> >>>>> Hi all,<br>
> >>>>><br>
> >>>>> Multiple projects are suffering from db lock timeouts due to<br>
> >>>>> deadlocks deep in mysqldb library that we use to interact with<br>
> >>>>> mysql servers. In essence, the problem is due to missing eventlet<br>
> >>>>> support in mysqldb module, meaning when a db lock is encountered,<br>
> >>>>> the library does not yield to the next green thread, allowing other<br>
> >>>>> threads to eventually unlock the grabbed lock, and instead it just<br>
> >>>>> blocks the main thread, that eventually raises timeout exception<br>
> >>>>> (OperationalError).<br>
> >>>>><br>
> >>>>> The failed operation is not retried, leaving failing request not<br>
> >>>>> served. In Nova, there is a special retry mechanism for deadlocks,<br>
> >>>>> though I think it's more a hack than a proper fix.<br>
> >>>>><br>
> >>>>> Neutron is one of the projects that suffer from those timeout<br>
> >>>>> errors a lot. Partly it's due to lack of discipline in how we do<br>
> >>>>> nested calls in l3_db and ml2_plugin code, but that's not something<br>
> >>>>> to change in foreseeable future, so we need to find another<br>
> >>>>> solution that is applicable for Juno. Ideally, the solution should<br>
> >>>>> be applicable for Icehouse too to allow distributors to resolve<br>
> >>>>> existing deadlocks without waiting for Juno.<br>
> >>>>><br>
> >>>>> We've had several discussions and attempts to introduce a solution<br>
> >>>>> to the problem. Thanks to oslo.db guys, we now have more or less<br>
> >>>>> clear view on the cause of the failures and how to easily fix them.<br>
> >>>>> The solution is to switch mysqldb to something eventlet aware. The<br>
> >>>>> best candidate is probably MySQL Connector module that is an<br>
> >>>>> official MySQL client for Python and that shows some (preliminary)<br>
> >>>>> good results in terms of performance.<br>
> >>>><br>
> >>>> I've made additional testing, creating 2000 networks in parallel (10<br>
> >>>> thread workers) for both drivers and comparing results.<br>
> >>>><br>
> >>>> With mysqldb: 215.81 sec<br>
> >>>> With mysql-connector: 88.66<br>
> >>>><br>
> >>>> ~2.4 times performance boost, ok? ;)<br>
> >>>><br>
> >>>> I think we should switch to that library *even* if we forget about all<br>
> >>>> the nasty deadlocks we experience now.<br>
> >>>><br>
> >>>>><br>
> >>>>> I've posted a Neutron spec for the switch to the new client in Juno<br>
> >>>>> at [1]. Ideally, switch is just a matter of several fixes to<br>
> >>>>> oslo.db that would enable full support for the new driver already<br>
> >>>>> supported by SQLAlchemy, plus 'connection' string modified in<br>
> >>>>> service configuration files, plus documentation updates to refer to<br>
> >>>>> the new official way to configure services for MySQL. The database<br>
> >>>>> code won't, ideally, require any major changes, though some<br>
> >>>>> adaptation for the new client library may be needed. That said,<br>
> >>>>> Neutron does not seem to require any changes, though it was<br>
> >>>>> revealed that there are some alembic migration rules in Keystone or<br>
> >>>>> Glance that need (trivial) modifications.<br>
> >>>>><br>
> >>>>> You can see how trivial the switch can be achieved for a service<br>
> >>>>> based on example for Neutron [2].<br>
> >>>>><br>
> >>>>> While this is a Neutron specific proposal, there is an obvious wish<br>
> >>>>> to switch to the new library globally throughout all the projects,<br>
> >>>>> to reduce devops burden, among other things. My vision is that,<br>
> >>>>> ideally, we switch all projects to the new library in Juno, though<br>
> >>>>> we still may leave several projects for K in case any issues arise,<br>
> >>>>> similar to the way projects switched to oslo.messaging during two<br>
> >>>>> cycles instead of one. Though looking at how easy Neutron can be<br>
> >>>>> switched to the new library, I wouldn't expect any issues that<br>
> >>>>> would postpone the switch till K.<br>
> >>>>><br>
> >>>>> It was mentioned in comments to the spec proposal that there were<br>
> >>>>> some discussions at the latest summit around possible switch in<br>
> >>>>> context of Nova that revealed some concerns, though they do not<br>
> >>>>> seem to be documented anywhere. So if you know anything about it,<br>
> >>>>> please comment.<br>
> >>>>><br>
> >>>>> So, we'd like to hear from other projects what's your take on that<br>
> >>>>> move, whether you see any issues or have concerns about it.<br>
> >>>>><br>
> >>>>> Thanks for your comments, /Ihar<br>
> >>>>><br>
> >>>>> [1]: <a href="https://review.openstack.org/#/c/104905/">https://review.openstack.org/#/c/104905/</a> [2]:<br>
> >>>>> <a href="https://review.openstack.org/#/c/105209/">https://review.openstack.org/#/c/105209/</a><br>
> >>>>><br>
> >>>>> _______________________________________________ OpenStack-dev<br>
> >>>>> mailing list <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">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> >>>>><br>
> >>>> -----BEGIN PGP SIGNATURE-----<br>
> >>>> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)<br>
> >>>> Comment: Using GnuPG with Thunderbird - <a href="http://www.enigmail.net/">http://www.enigmail.net/</a><br>
> >>>><br>
> >>>> iQEcBAEBCgAGBQJTv9LHAAoJEC5aWaUY1u57d2cIAIAthLuM6qxN9fVjPwoICEae<br>
> >>>> oSOLvaDNPpZ+xBBqKI+2l5aFiBXSkHzgCfWGHEZB4e+5odAzt8r3Dg5eG/hwckGt<br>
> >>>> iZLPGLxcmvD5K0cRoSSPWkPC4KkOwKw0yQHl/JQarDcHQlLgO64jx3bzlB1LDxRu<br>
> >>>> R/Bvqo1SBo8g/cupWyxJXNViu9z7zAlvcHLRg4j/AfNTsTDZRrSgbMF2/gLTMvN2<br>
> >>>> FPtkjBvZq++zOva5G5/TySr1b3QRBFCG0uetVbcVF//90XOw+O++rUiDW1v7vkA9<br>
> >>>> OS2sCIXmx1i8kt9yuvs0h11MS8qfX9rSXREJXyPq6NDmePdQdKFsozMdTmqaDfU=<br>
> >>>> =JfiC<br>
> >>>> -----END PGP SIGNATURE-----<br>
> >>>><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">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> >>><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">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> >>><br>
> >><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">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> ><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">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><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">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
</p>