Hi!
You have probably missed the original message. I have pointed that
I have build Mysql 3.23.33 from the original TAR ball on
FreeBSD 4.2-STABLE using comiler options which are used
in the port of MySQL for FreeBSD, so it does not crush
on high loads. After all this i am getting server crushed by
using INSERT DELAYED.
As for REPLACE/INSERT lockup, i figured that it could
happen when there is no space left on device.
Artem
----- Original Message -----
From: "Sinisa Milivojevic" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, February 23, 2001 3:23 PM
Subject: Re: INSERT/REPLACE lock up in 3.23.33
> Steven Roussey writes:
> > > My troubles continue with INSERTs (i posted a message about
INSERT
> > > DELAYED crushing a server before). Now, I have this:
> >
> > We are running Linux and MySQL 3.23.30 and have similar problems.
In
> > particular we have a lot of INSERT DELAYEDs into a fixed table,
and REPLACE
> > DELAYED into a variable size table. At some point the handlers
never finish
> > a query and then fill up handler, then fill up all other
processes with
> > queries that are waiting for the table and then I have to kill -9
it from
> > the commandline.
> >
> > This only seems to happen if the tables are really big for the
REPLACEs.
> > I've tested it starting with multi-GB tables and then with empty
ones. I see
> > the slow query and lock up situation with the bigger tables.
> >
> > I can't make a real test case, save for copying from one multiGig
table into
> > another, perhaps, while also streaming in other log data into the
logging
> > table we have. I wish we could have a replay software so it gets
the timing
> > the same to see what is going on thread-wise.
> >
> > Oh, well. Let me know if you figure this out.
> >
> > Sincerely,
> >
> > Steven Roussey
> > Network54.com
> > http://network54.com/?pp=e
> >
> >
>
>
> Hi!
>
> Only few words. Problems with DELAYED ops on Linux are usually
related
> to broken LinuxThreads.
>
> Safest thing for you is to use our latest 3.23 binaries which are
> statically linked with stable glibc and with some additional
patches.
>
> There can be another source of problems with REPLACE. As it has to
> DELETE a row first, it might take a lot of time on huge table if
MySQL
> is not able for some reason to utilize index in order to locate
rows.
>
>
> Regards,
>
> Sinisa
>
> ____ __ _____ _____ ___ == MySQL AB
> /*/\*\/\*\ /*/ \*\ /*/ \*\ |*| Sinisa Milivojevic
> /*/ /*/ /*/ \*\_ |*| |*||*| mailto:[EMAIL PROTECTED]
> /*/ /*/ /*/\*\/*/ \*\|*| |*||*| Larnaca, Cyprus
> /*/ /*/ /*/\*\_/*/ \*\_/*/ |*|____
> ^^^^^^^^^^^^/*/^^^^^^^^^^^\*\^^^^^^^^^^^
> /*/ \*\ Developers Team
>
>
>
> --------------------------------------------------------------------
-
> 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
>
>
---------------------------------------------------------------------
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
