Hi,
the inserts did not change the state after the select finished. The network is
running full duplex but the only problem I ever encountered with the cards was
initalization on fast systems. I fixed this and posted it to the linux kernel
mailing list (search for epic100).
If the problem continues to appear with the slaves stopped I'll try to code a
reproducable test case.
The only thing that's visible is the following entry in the slow query log
which matches the process list attached to my earlier mail. The funny thing is
that this query will result in exactly one row and according to the log the
this row was sent. The query time, however, of 277 seconds for a somewhat
simple query makes me wonder...
# Time: 010205 23:13:00
# User@Host: logreader[logreader] @ [10.1.1.4]
# Time: 277 Lock_time: 0 Rows_sent: 1
use syslog;
select max(swap_used+swap_free) from pcp where host='castor' and
time>='20010204230000' and time<'20010205231000';
On 06-Feb-2001 Sinisa Milivojevic wrote:
> Andreas Steinmetz writes:
> > Hi,
> > well, the query is over a network. Single switch with two VLANs between
> the
> > systems, network speed is *200MBit/s*. The php code structure executing
> was:
> >
> > ... prepare query ...
> > mysql_connect();
> > mysql_query();
> > mysql_fetch_row();
> > mysql_close();
> > ... process and send data to browser ...
> >
> > The table the query executed on did have a total of about 25000 rows at
> that
> > time. The query executing had to return exacty one row (max()). When the
> query
> > thread did terminate all threads waiting for inserts did keep *hanging*
> either
> > in state 'System lock' or state 'Opening table'. Thus:
> >
> > The whole database was *deadlocked* with only insert queries pending after
> a
> > a data retrieval query thread did execute. In this state a regular
> shutdown
> > of the database is *not* possible, you have to send SIGTERM to shut down
> > mysql. Oh, the same thing did happen *again* today.
> >
> > The behaviour looks like in some cases mysql doesn't unlock after a data
> > retrieval query or that pending inserts don't get properly restarted.
> >
> > As a hint the inserting daemons keep continously connected to mysql as
> long as
> > the database is up, there are automatic reconnect attempts in case the
> database
> > is not available.
> >
> > To finally assert that replication isn't involved I'm running this now
> with the
> > slaves stopped.
> >
> > If it happens again I will try to set up code that is able to reproduce
> the
> > problem on a test system (single database without replication there).
> >
>
>
> HI!
>
> Did INSERT queries changed their state after SELECT has finished
> sending data ??
>
> What OS is that and is there anything in the error log file that might
> indicate some problems ??
>
> If you are using Linux, there could be some problems with fast
> Ethernet cards in duplex mode. If that is a case, please try disabling
> duplexing (on hubs and switches). Also enable compression.
>
> And yes, we would be very much interested in repeatable test case.
>
>
> Regards,
>
> Sinisa
>
> ____ __ _____ _____ ___ == MySQL AB
> /*/\*\/\*\ /*/ \*\ /*/ \*\ |*| Sinisa Milivojevic
> /*/ /*/ /*/ \*\_ |*| |*||*| mailto:[EMAIL PROTECTED]
> /*/ /*/ /*/\*\/*/ \*\|*| |*||*| Larnaka, Cyprus
> /*/ /*/ /*/\*\_/*/ \*\_/*/ |*|____
> ^^^^^^^^^^^^/*/^^^^^^^^^^^\*\^^^^^^^^^^^
> /*/ \*\ Developers Team
>
Andreas Steinmetz
D.O.M. Datenverarbeitung GmbH
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
