Re: 2.6.0-test2-mm3 and mysql

["Heikki Tuuri" <Heikki.Tuuri@innodb.com>]

Denis,

----- Original Message ----- 
From: "Denis Vlasenko" <vda@port.imtp.ilyichevsk.odessa.ua>
To: "Heikki Tuuri" <Heikki.Tuuri@innodb.com>; <linux-kernel@vger.kernel.org>
Sent: Monday, August 04, 2003 3:24 PM
Subject: Re: 2.6.0-test2-mm3 and mysql


> On 3 August 2003 13:43, Heikki Tuuri wrote:
> > > Well there's a problem.  We're kernel people, not database people.  I,
for
> > > one, would not have a clue how to set such a thing up.
> > >
> > > If someone could prepare a simple-enough-for-kernel-people description
of
> > > how to get such a test up and running, then we might make some
progress.
> >
> > ok :).
> >
> > 1. Download
>
> [4 screenfuls snipped]
>
> That's a hell of a setup work, and kernel folks will always get slightly
> different setups. Can database folks make a fully configured chrootable
> tarball for mysql stress testing?

I think an even better idea is to use some multithreaded file i/o stress
test program. There probably are such programs already. If not, write a
simple C program which calls pread(), pwrite(), and fsync() on pages of size
2 - 16 kB. Vary the data you write, and check that the data you read is what
you wrote to the file the last time. Run the test for several days or even
weeks. Vary the size of the files so that you get real disk reads.

Is there such a stress test in the standard test suite for Linux
kernel/driver developers?

Running an actual SQL database on top of that file i/o workload may also
have some effect, because it is possible some bugs are really corruption of
the process memory space. Maybe we could simulate the database CPU load by
simple memcpy's etc.

Some additional info I forgot to mention about corruption:

1. In some cases corruption happens very frequently, even several times per
hour. In those cases I suspect a hardware fault. In addition to mysqld, also
other programs may suffer and crash.

2. Most cases of corruption only happen once in several weeks. They require
heavy database load to manifest.

3. A typical case of corruption is that an area of size varying from 4 bytes
to 4 kB is reset to zero in a 16 kB database page. Often is has been the end
of the page. In Sergey's case the whole 16 kB page was reset to zero.

> --
> vda

Regards,

Heikki
http://www.innodb.com