Thanks Jonathan!
We've been meaning to get into more serious failure/negative testing for a
while now. I'll take note of your advice, as it will be useful when we get
there.
André
On Fri, Oct 27, 2017 at 7:54 PM, Jonathan Vanasco
wrote:
>
>
> On Friday, October 27,
On Friday, October 27, 2017 at 10:26:50 AM UTC-4, André Caron wrote:
>
> FYI, I tried this out and updated my GitHub project to reflect your
> excellent insight.
>
Since your connections were large enough to notice an effect in production,
if you have spare time I suggest doing some tests to
FYI, I tried this out and updated my GitHub project to reflect your
excellent insight.
Thanks again!
André
On Thu, Oct 26, 2017 at 11:40 PM, André Caron
wrote:
> Thanksl Mike and Jonathan! I wasn't expecting such good advice and such
> detailed responses so quickly
Thanksl Mike and Jonathan! I wasn't expecting such good advice and such
detailed responses so quickly :-)
> The rationale they give is sort of along the lines of what my thinking
was as well, that of the "misbehaving database connection" that leaks memory
either on the client or server and needs
On a related note, I suggest implementing the timeout as happening at a
random time within a 2-3 minute window (e.g. at 2 minutes there is an
increasing 25% chance of a reconnect, at 3 minutes it jumps up to 75%).
This should scatter reconnects during periods of high load.
A property I
On Thu, Oct 26, 2017 at 5:36 AM, André Caron wrote:
> Hi there!
>
> It's my first time on this list. Don't be shy to tell me if this isn't the
> right channel to discuss this :-)
>
> When looking at MySQL metrics on our production deployment of MySQL, I
> noticed a
Hi there!
It's my first time on this list. Don't be shy to tell me if this isn't the
right channel to discuss this :-)
When looking at MySQL metrics on our production deployment of MySQL, I
noticed a hammer effect in the number of new connections to MySQL. In
short, when there is a sudden