Re: bugs Digest 29 Sep 2004 18:58:38 -0000 Issue 636

On Wed, Sep 29, 2004 at 01:38:03PM -0700, philo vivero wrote:
> > -----------------------------------------------------------
> > From: Ed Korthof <[email protected]>
> > Subject: intermittent 'Lost connection to MySQL server' errors w/ DBI
>  . . .
> > Lost connection to MySQL server during query at ./mysql_running line 33.
>  . . .
> > Our my.cnf looks like this:
> > 
> >     [mysqld]
> >     set-variable=max_allowed_packet=10485760
> >     set-variable=max_connections=355
> 
> 1. The my.cnf is the same on all boxes? What does "show variables like
> '%t_timeout%'" give on at least the box that's broken and one that
> isn't? We're looking specifically for "wait_timeout" and
> "connect_timeout".

There are machines with exactly the same my.cnf which work fine.  I did
my testing on a machine where max_connections was slightly higher, but
reducing it to 355 doesn't change the fact that I can't reproduce it on
the other machine.

We did check the timeouts, but the numbers didn't show anything
interesting AFAICT -- 

| connect_timeout        | 5     |
| delayed_insert_timeout | 300   |
| interactive_timeout    | 28800 |
| net_read_timeout       | 30    |
| net_write_timeout      | 60    |
| wait_timeout           | 28800 |

...

> 2. Any firewall rules on either box? Find out what, if any, firewall
> software you have running. ipfw? iptables? Check the rules. Make sure
> nothing is closing "inactive" connections or otherwise closing
> connections.
>
> 3. Assuming the above turn up no clues, ask your Unix admin (if it isn't
> you) to look at the network layer. Packet loss? Transmit errors? All the
> usual suspects.

I'd say the nework isn't the issue because the access is on the same
machine, using a unix domain socket.  Sorry, I should have been clearer
about that -- it's in the strace out, but it should have been mentioned
at the top.  Otherwise, i'd also have tried tcpdump...

The only thing I haven't tried is strace on the MySQL server, largely
because I'd like to know where to look (or which syscalls are relevant)
-- there's too much output for this to be useful without some way to
pare down the amount of data.  

... also, that might make it harder to reproduce -- I should have
mentioned one more thing: turning on MySQL query logging made it harder
to reproduce this.  It was still possible, but I had to increase the
loop I used for this from 450 (1000 was more than enough).  

We did the calls with bash loops, but it's as easy w/ perl:

perl -e 'foreach $i (1..1000) { system("./mysql_running &"); }'

...

thanks --

Ed

-- 
   +=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=
   |   Ed Korthof   |  [email protected]  |   650-228-2527   |
   +=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=

-- 
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe:    http://lists.mysql.com/[email protected]