On Fri, Sep 07, 2001 at 07:19:01AM -0700, Mike Wexler wrote:
>
> Jeremy Zawodny wrote:
> >
> > On Fri, Sep 07, 2001 at 12:07:07PM +0100, Basil Hussain wrote:
> > >
> > > I'm quite surprised that this level of performance is available from
> > > such standard (well, not standard as in 'common', but y'know what I
> > > mean...) hardware. The last I heard, 1K+ queries/sec was only being
> > > done on extremely high-end Sun enterprise-level machines.
> >
> > Yeah, they *were* almost all read queries...
> >
> > > On the other hand though, it gives me some comfort that the hardware
> > > being used in my operation will meet any future needs. We have
> > > similar spec servers (P3-1Ghz dual-cpu, 512Mb RAM, 3x36Gb SCSI
> > > RAID5). Maybe I should try out mysql-super-smack and see what kind
> > > of numbers it turns up. :-)
> >
> > It would be interesting.
> >
> > We've just finished some upgrades here (thus the recent low uptimes in
> > my signature). Brought out Linux boxes up to 2.4.9 and 2GB of RAM.
> > Had a lot of problems with 2.4.9's brain-dead VM subsystem, so I
> > disabled swap and things are A LOT better now.
>
> Could you provide more details about the problems with 2.4.9's VM and
> how and why you disabled swap?
I can give a short explanation until I find the time to do something
more complete...
We had a couple of Linux 2.2.19 servers with 2 CPUs (P3-850) and 1GB
of RAM. They were solid and they flew. The never swapped. They had
well tuned my.cnf files. But we needed large files and ReiserFS, so
we upgraded to 2.4.9.
After the upgrade, IO performance on the master server began to suck
at backup/snapshot time. In fact, Linux claimed that it was running
out of RAM. So we added RAM (a 2nd gigabyte). The problem didn't go
away.
So I poked around and watched it really closely for a couple days.
What I found is that the server would run pretty well until I
initiated some other type of intensive IO in addition to MySQL. For
example, I'd copy a 3GB data file from the main RAID-5 data volume to
/tmp. As it copied, Linux decided to swap out most of mysqld (which
is in the neighborhood of 400MB) to use it for a disk buffer. This
not only killed MySQL performance, because it had to swap those pages
back into physical memory as soon as they were needed, it also made
the copy take much longer than it should have.
I could go on, but the pattern was clear. Linux tried to use as much
memory as it could for disk buffering--even if it meant "stealing" RAM
from mysqld.
The solution? I disabled swap and it's been humming along just fine
ever since. After all, with 2GB of RAM and a good understanding of
what our RAM requirements really are, the system should never swap.
It was tried to be smarter than me and it failed. It felt very
Microsoft-like. :-(
Jeremy
--
Jeremy D. Zawodny, <[EMAIL PROTECTED]>
Technical Yahoo - Yahoo Finance
Desk: (408) 349-7878 Fax: (408) 349-5454 Cell: (408) 685-5936
MySQL 3.23.41-max: up 4 days, processed 104,862,576 queries (245/sec. avg)
---------------------------------------------------------------------
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
