Re: [sqlalchemy] Re: Pool connections high-water, session query counter?

doesn't sound like a lock (MySQL is a very un-lockish database), sounds like you have a query that occasionally returns a huge number of rows, such as from a broken JOIN condition or similar.The occasional nature without any errors, as well as that the operation you say should only be doing

[sqlalchemy] Re: Pool connections high-water, session query counter?

Turned on the slow query log, doesn't seem to be that. The fact that it isn't consistently bad for similar hits, and also seems to need some load to be exposed makes me thing either some contention while inside the request in Python, including lazy loads. I have been able to get some timings

Re: [sqlalchemy] several questions about connection pooling behaviour

Ok, thank you for the answer, appreciate it. пятница, 1 сентября 2017 г., 21:11:26 UTC+3 пользователь Mike Bayer написал: > > On Fri, Sep 1, 2017 at 12:35 PM, Антонио Антуан > wrote: > > Yes, I tried it and it is worked fine. > > Another thing that I tried to understand:

[sqlalchemy] Re: Pool connections high-water, session query counter?

what do your database and server logs show? are there slow query timeouts, deadlocks, etc? are these happening during peak load? 10-30 seconds looks more like an issue with competing locks or available workers, than potentially pool checkouts or lazy loading. aside from db logs, i've found

[sqlalchemy] Pool connections high-water, session query counter?

We have an internal Flask/SQLAlchemy webapp using MySQL and served up using Apache and mod_wsgi. We recently upgraded the server, going from an older Debian/Apache2.2/MySQL5.5/mod_wsgi 3.x, to a current Ubuntu/Apache 2.4/MySQL5.7/mod_wsgi4.5.x. Something seems to be causing some of our page

Re: [sqlalchemy] several questions about connection pooling behaviour

On Fri, Sep 1, 2017 at 12:35 PM, Антонио Антуан wrote: > Yes, I tried it and it is worked fine. > Another thing that I tried to understand: "Are connections, which used by > `session`, `session.bind`, compiled_query and engine, the same?". > `pg_stat_activity` shows me, that I

Re: [sqlalchemy] Updating pg8000 dialect following new release of pg8000

On Fri, Sep 1, 2017 at 12:09 PM, Tony Locke wrote: > No I don't think it's a bug because pg8000 is designed to always create a > prepared statement if one doesn't already exists, and so that entails > keeping some data for each prepared statement, steadily increasing memory

Re: [sqlalchemy] several questions about connection pooling behaviour

пятница, 1 сентября 2017 г., 18:08:35 UTC+3 пользователь Mike Bayer написал: > > On Fri, Sep 1, 2017 at 8:26 AM, Антонио Антуан > wrote: > > Hi guys. > > I have several questions and, possibly, misunderstandings about > sqlalchemy > > connection pooling behavior > > >

Re: [sqlalchemy] Updating pg8000 dialect following new release of pg8000

No I don't think it's a bug because pg8000 is designed to always create a prepared statement if one doesn't already exists, and so that entails keeping some data for each prepared statement, steadily increasing memory use. There's a pg8000.max_prepared_statements parameter (set to 1000 by default)

Re: [sqlalchemy] Updating pg8000 dialect following new release of pg8000

On Fri, Sep 1, 2017 at 10:57 AM, Tony Locke wrote: > So, next problem. The test > test/aaa_profiling/test_memusage.py::MemUsageWBackendTest_postgresql+pg8000_9_5_8::test_many_updates > fails because pg8000 creates a new prepared statement for each unique sql > statement,

Re: [sqlalchemy] replicating/triggering a session connection issue for testing?

thank you kindly, mike! On Friday, September 1, 2017 at 10:51:16 AM UTC-4, Mike Bayer wrote: > > for simulating connection problems I use mock heavily.If you look > at test/engine/test_reconnect.py you can see there's a whole MockDBAPI > that can be instructed to "expode" in a specific way.

Re: [sqlalchemy] several questions about connection pooling behaviour

On Fri, Sep 1, 2017 at 8:26 AM, Антонио Антуан wrote: > Hi guys. > I have several questions and, possibly, misunderstandings about sqlalchemy > connection pooling behavior > > 1. I try to figure out if this is normal: >

Re: [sqlalchemy] Updating pg8000 dialect following new release of pg8000

Thanks Mike, fetching the latest commits from SQLAlchemy solved the 'unicode' problem. Looking at the multiprocess problem, the pg8000 driver holds global state for remembering the prepared statements it's created. This means that it fails if multiple processes access it, even if the access is

Re: [sqlalchemy] replicating/triggering a session connection issue for testing?

for simulating connection problems I use mock heavily.If you look at test/engine/test_reconnect.py you can see there's a whole MockDBAPI that can be instructed to "expode" in a specific way. On Thu, Aug 31, 2017 at 9:30 PM, Jonathan Vanasco wrote: > I discovered an

[sqlalchemy] Re: several questions about connection pooling behaviour

пятница, 1 сентября 2017 г., 15:26:11 UTC+3 пользователь Антонио Антуан написал: > > Hi guys. > I have several questions and, possibly, misunderstandings about sqlalchemy > connection pooling behavior > > 1. I try to figure out if this is normal: >

[sqlalchemy] several questions about connection pooling behaviour

Hi guys. I have several questions and, possibly, misunderstandings about sqlalchemy connection pooling behavior 1. I try to figure out if this is normal: https://gist.github.com/aCLr/be78f3495892978ee868c9b5adcef0e6 As you can see, I checked that `bind` is the same on `get_bind()` invokation