On 06/12/2012 05:10 AM, Johan De Meersman wrote:
> ----- Original Message -----
>> From: "Claudio Nanni"<claudio.nanni@stripped>
>> " Print out warnings such as Aborted connection... to the error log."
>> the dots are not telling if they comprise Aborted clients as well.
> Hah, how's that for selective blindness. Totally missed that :-)
>> I find the MySQL error log extremely poor, as far as I know it is one
>> of the MySQL features (like authentication) stuck to the dawn of
>> MySQL times.
>> Very hard to debug non basic things like your issue.
>> From what I have experienced usually Aborted connection means wrong
>> credentials while Aborted clients means the client (typically PHP)
>> did not close the connection properly.
> Yep, that's it; but indeed, since aborted clients aren't logged, then, I seem to be
> in a ditch.
>> Do you have any chance to check if the code is closing the
>> connections to the mysql database?
> Oh, yes, millions upon billions of lines of wonderfully obscure Java stacktraces that
> reveal little more than "Lost connection to database" for every couple of thousand lines.
> Everything works fine most of the time, then randomly some queries will get slow, and
> eventually the connections will drop. Rinse and repeat.
> Oh well. Thanks for pointing out my reading error, I'm off to lart the devs into
> profiling their code to figure out *what* causes the slowness. Guess I'll have to set up
> some tcpdumps, too.
Watch out for this one, especially if the Aborted connections are all
getting charged against a single client. Per the URL below and a
misbehaving application not closing connections correctly, I've seen
this spontaneously blacklist a client IP. Only way to unblacklist after
is to run "flush-hosts" on the mysql server.
Also, didn't see a one-to-one correspondence between the global
max_connect_errors setting and Aborted_connects (from show global status
like '%abort%';), so hard to tell when you're approaching the per client