At 13:08 +0100 12/19/02, Harald Fuchs wrote:
In article <[EMAIL PROTECTED]>,
Dyego Souza do Carmo <[EMAIL PROTECTED]> writes:
DobrĂ½ den,
quarta-feira, 18 de dezembro de 2002, 13:10:07, napsal jste:
MTB> Qunfeng Dong wrote:
Another thing, with some linux system, there is a size
limit for file. MySQL seems to store each of its table
as single file. You need to choose a file system
without that limit.
MTB> Just use InnoDB tables for these files and you won't have a problem
MTB> AFAIK; you can have multiple 2G files that are used to create one big
MTB> table if you like (any InnoDB people want to comment on actual limits?)
Use the InnoDB tables with the raw devices ( ex: allow innodb use a
/dev/sdxx or /dev/hdxx to write tablespace ), the speed is better,
MySQL don't loses time with the filesystem.
In my production database , i have a tablespace with 130G ( with raw
diveces on SCSI disks) and the performance is good :)
/dev/sdxx or /dev/hdxx are _not_ raw devices; they are disk partitions
without a file system, but still subject to the Linux buffer cache.
"man 8 raw" says how to bind a disk partition to a true raw device
(/dev/raw/rawX). And yes, those beasts work fine with InnoDB.
I asked Heikki about this. His reply:
Paul,
you can use a disk partition which Linux buffers in its file cache, and you
can use also a 'raw device disk partition' which Linux probably does not
buffer.
Google the mailing list. In summer a Swiss user was able to get a raw device
working as a data file.
I have no measurements of performance raw device / buffered disk partition.
In theory, a raw device should be faster. fsync was extremely slow in
Linux-2.2, and is still a bit slow in 2.4.
Regards,
Heikki
-
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