I'd say that if your database can fit on the SCSI drive you can afford, there
is no reason for not choosing SCSI. Or, hec, if it's a really small database,
why not ramdist?
In regard to your question about whether it confirms a write before commiting
a transaction. First of all, check to see i
Thomas S. Iversen wrote:
> Back to the question: we're on a limited budget, and have to choose
> between either inexpensive but large IDE disk or fast but small SCSI
> disks. The machine has 1GB memory. First thought would be IDE disks since
> we have enough memory to cache the DBs.
If you're
Hi
This is not an atempt to start a flamewar!!
We're about to build a db server for educational purposes. Running 150+
databases pr. semester. Nothing big, nothing demanding when looking at a
single database, but combined it may give some load (might be a lot of
concurrent activity during class
Since the intention of fsync and fdatasync seems to be
to write dirty fs buffers to persistent storage (i.e.
the "oxide") then the best time is not necessarily
the objective. Given the IDE times that people have
been reporting, it is very unlikely that any of those
IDE disks were really doing 200
Hello,
Michael Widenius wrote on Monday, March 05, 2001:
>
> I wonder from where the fdatasync() is comming; MySQL is not doing
> those (if you are not running mysqld with --flush)
The call is either a fsync or an fdatasync that is done by Berkley DB on the
transaction log.
Regards,
Chris Dela
Hi!
> "Jeremy" == Jeremy Hansen <[EMAIL PROTECTED]> writes:
Jeremy> We're doing some mysql benchmarking. For some reason it seems that ide
Jeremy> drives are currently beating a scsi raid array and it seems to be related
Jeremy> to fsync's. Bonnie stats show the scsi array to blow away id
Hi!
> "Mike" == Mike Black <[EMAIL PROTECTED]> writes:
Mike> Here's a strace -r on IDE:
Mike> 0.001488 write(3, "\214\1\0\0Blah Blah Blah Blah Blah Bla"..., 56) = 56
Mike> 0.000516 fdatasync(0x3)= 0
Mike> 0.001530 write(3, "\215\1\0\0Blah Blah Blah Blah Blah Bla".
Douglas Gilbert wrote:
> There is definitely something strange going on here.
> As the bonnie test below shows, the SCSI disk used
> for my tests should vastly outperform the old IDE one:
First thank you and others with my clueless investigation about
the module loading under Debian GNU/Linux. (I
TECTED] 321-676-2923,x203
> http://www.csihq.com Computer Science Innovations
> http://www.csihq.com/~mike My home page
> FAX 321-676-2355
> - Original Message -
> From: "Jeremy Hansen" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Cc: <[EMA
This is just a guess - I have significant experience of Scsi drives but none of Unix
internals. To
do a good sync, you have to force the data from the CPU to the disk, and from the disk
ram onto the
disk oxide. IDE disks are not very clever, and I do not think that they cache
unwritten data. If
<[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, March 02, 2001 11:27 AM
Subject: scsi vs ide performance on fsync's
We're doing some mysql benchmarking. For some reason it seems that ide
drives are currently beating a scsi raid array an
We're doing some mysql benchmarking. For some reason it seems that ide
drives are currently beating a scsi raid array and it seems to be related
to fsync's. Bonnie stats show the scsi array to blow away ide as
expected, but mysql tests still have the idea beating on plain insert
speeds. Can an
12 matches
Mail list logo
