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 a
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
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 (Silic
s 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.
>
>
> 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
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 no
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 respond
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 that
> * - 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
> -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&
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
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 differ
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 f
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.
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 d
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 tha
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 driv
y, July 12, 2006 3:59 PM
> To: mysql@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
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 will
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 ou
>
> 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
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
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
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 f
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, slappe
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 thr
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
> 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
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 better
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 will
30 matches
Mail list logo
