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
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
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:
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
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
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
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
пятница, 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
> >
>
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)
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,
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.
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:
>
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
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
пятница, 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:
>
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
16 matches
Mail list logo