On Wednesday 12 July 2006 20:58, Chris White wrote:
performance?. From what I know of MySQL, not really, because MySQL does a
good amount of work in memory. The only time I'd see disk access being a
factor is if you had a large mass of swap/virtual memory.
I have to play with 300 gig of
Duncan Hill wrote:
Oh, as a small example - the DB server attached to the SAN can pull data
faster than my personal server, even though the personal server is only
dealing with one request and the DB/SAN is dealing with hundreds per second
(and the personal server is no slouch). Fun to watch
We're using Opterons, Linux 2.6.x, and a SiL (Silicon Image) SATA
chipset whose particular model number I don't have in front of me.
After MUCH MUCH MUCH trial and error we've discovered that:
1) 2.6.16 substantially alleviates the problem but doesn't eliminate it.
2) There is a 3Ware card
and binlogs and data together?
TIA,
Tim
-Original Message-
From: Tim Lucia [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 12, 2006 5:41 PM
To: 'Chris White'; mysql@lists.mysql.com
Subject: RE: I don't understand why SCSI is preferred.
-Original Message-
From: Chris White
It was my impression, from the information we've collected that our
problem is very specific to Opteron. It's possible that your problem
is actually unrelated. :(
-JF
On Jul 14, 2006, at 7:24 AM, living liquid|Christian Meisinger wrote:
We're using Opterons, Linux 2.6.x, and a SiL
* - For example: We faced a NASTY problem using AMD 64-bit CPUs + SATA +
Linux where I/O on the system (the WHOLE system, not JUST the SATA
spindles -- network, PATA, USB, EVERYTHING) would suddenly come to a
grinding halt (or very nearly halted) randomly when the SATA subsystem
was under
We're using Opterons, Linux 2.6.x, and a SiL (Silicon Image) SATA
chipset whose particular model number I don't have in front of me.
After MUCH MUCH MUCH trial and error we've discovered that:
1) 2.6.16 substantially alleviates the problem but doesn't eliminate it.
2) There is a 3Ware card
At 03:45 PM 7/12/2006, Jon Frisby wrote:
This REALLY should be an academic concern. Either you have a system
that can tolerate the failure of a drive, or you do not. The
frequency of failure rates is pretty much irrelevant: You can train
incredibly non-technical (inexpensive) people to
On Jul 13, 2006, at 3:03 PM, mos wrote:
At 03:45 PM 7/12/2006, Jon Frisby wrote:
This REALLY should be an academic concern. Either you have a system
that can tolerate the failure of a drive, or you do not. The
frequency of failure rates is pretty much irrelevant: You can train
incredibly
On 7/11/06, Brian Dunning [EMAIL PROTECTED] wrote:
My understanding is that SCSI has a faster transfer rate, for
transferring large files. A busy database needs really fast access,
Your statement is partially correct, yes, it has faster transfer
rates, but that is not only for tranfer large
On Tuesday 11 July 2006 19:26, mos wrote:
SCSI drives are also designed to run 24/7 whereas IDE drives are more
likely to fail if used on a busy server.
This used to be the case. But there are SATA drives out there now being made
for enterprise class, 100% duty cycle operations. See, for
At 12:42 PM 7/12/2006, you wrote:
On Tuesday 11 July 2006 19:26, mos wrote:
SCSI drives are also designed to run 24/7 whereas IDE drives are more
likely to fail if used on a busy server.
This used to be the case. But there are SATA drives out there now being made
for enterprise class, 100%
I am hoping the newer SATA II drives will provide SCSI performance at a
reasonable price. It would be interesting to see if anyone has polled ISP's
to see what they're using. I know they charge more (or at least they used
to) for SCSI drives if you are renting a server from them. It
On 7/12/06, mos [EMAIL PROTECTED] wrote:
At 12:42 PM 7/12/2006, you wrote:
On Tuesday 11 July 2006 19:26, mos wrote:
SCSI drives are also designed to run 24/7 whereas IDE drives are more
likely to fail if used on a busy server.
This used to be the case. But there are SATA drives out there
On Tuesday 11 July 2006 04:18 pm, Brian Dunning wrote:
My understanding is that SCSI has a faster transfer rate, for
transferring large files. A busy database needs really fast access,
for making numerous fast calls all over the disk. Two different,
unrelated things.
I am more than willing
@lists.mysql.com
Subject: Re: I don't understand why SCSI is preferred.
On Tuesday 11 July 2006 04:18 pm, Brian Dunning wrote:
My understanding is that SCSI has a faster transfer rate, for
transferring large files. A busy database needs really fast access,
for making numerous fast calls
This REALLY should be an academic concern. Either you have a system
that can tolerate the failure of a drive, or you do not. The
frequency of failure rates is pretty much irrelevant: You can train
incredibly non-technical (inexpensive) people to respond to a pager
and hot-swap a bad
On Wednesday 12 July 2006 20:11, mos wrote:
To get the MTBF estimate, the manufacturer will power on 100 drives (or
more) and time to see when the first one fails. If it fails in 1000 hours,
then the MTBF is 100x1000hrs or 100,000 hours.
I don't know much statistics,
but I do know that that
On Jul 12, 2006, at 12:45 PM, Scott Tanner wrote:
I am hoping the newer SATA II drives will provide SCSI performance
at a
reasonable price. It would be interesting to see if anyone has
polled ISP's
to see what they're using. I know they charge more (or at least
they used
to) for SCSI
On Jul 12, 2006, at 12:56 PM, Daniel da Veiga wrote:
On 7/12/06, mos [EMAIL PROTECTED] wrote:
At 12:42 PM 7/12/2006, you wrote:
On Tuesday 11 July 2006 19:26, mos wrote:
SCSI drives are also designed to run 24/7 whereas IDE drives
are more
likely to fail if used on a busy server.
This
On Wednesday 12 July 2006 01:13 pm, Tim Lucia wrote:
I've seen whitepapers from MySQL's web site, co-authored with Dell, that
recommend the hardware optimization be:
1. More Memory
That's a definite
2. Faster Drives (15K RPM is better the 10K)
Well, I guess for any server really, the
On Jul 12, 2006, at 12:58 PM, Chris White wrote:
On Tuesday 11 July 2006 04:18 pm, Brian Dunning wrote:
My understanding is that SCSI has a faster transfer rate, for
transferring large files. A busy database needs really fast access,
for making numerous fast calls all over the disk. Two
On Wednesday 12 July 2006 01:13 pm, Tim Lucia wrote:
I've seen whitepapers from MySQL's web site, co-authored with Dell, that
recommend the hardware optimization be:
1. More Memory
2. Faster Drives (15K RPM is better the 10K)
3. Faster CPU.
Oh wait, we forgot #4:
4. Filesystem
You can
-Original Message-
From: Chris White [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 12, 2006 5:15 PM
To: mysql@lists.mysql.com
Subject: Re: I don't understand why SCSI is preferred.
On Wednesday 12 July 2006 01:13 pm, Tim Lucia wrote:
I've seen whitepapers from MySQL's web site
My understanding is that SCSI has a faster transfer rate, for
transferring large files. A busy database needs really fast access,
for making numerous fast calls all over the disk. Two different,
unrelated things.
I am more than willing to be called Wrong, slapped, and cast from a
bridge.
On Tuesday 11 July 2006 04:18 pm, Brian Dunning wrote:
My understanding is that SCSI has a faster transfer rate, for
transferring large files. A busy database needs really fast access,
for making numerous fast calls all over the disk. Two different,
unrelated things.
I am more than willing
Brian Dunning wrote:
My understanding is that SCSI has a faster transfer rate, for
transferring large files.
SCSI is better for EVERYTHING except your budget. Faster for large
transfers, small transfers, seek times, and most especially it handles
requests from multiple threads much
Brian Dunning wrote:
My understanding is that SCSI has a faster transfer rate, for
transferring large files.
SCSI is better for EVERYTHING except your budget. Faster for large
transfers, small transfers, seek times, and most especially it handles
requests from multiple threads much
On Tuesday, 11 July 2006 at 16:41:24 -0700, Chris White wrote:
On Tuesday 11 July 2006 04:18 pm, Brian Dunning wrote:
My understanding is that SCSI has a faster transfer rate, for
transferring large files. A busy database needs really fast access,
for making numerous fast calls all over the
It's my understanding that the biggest remaining difference has to do
with SCSI having far superior command queueing capabilities --
although SATA's command queueing may have closed the gap somewhat --
which provides for much better real-world performance when you have
multiple database
At 06:18 PM 7/11/2006, you wrote:
My understanding is that SCSI has a faster transfer rate, for
transferring large files. A busy database needs really fast access,
for making numerous fast calls all over the disk. Two different,
unrelated things.
I am more than willing to be called Wrong,
31 matches
Mail list logo
