On Wed, 2005-04-06 at 20:49 -0500, Steve Lord wrote:
> So if you want big fat files which get layed out in one chunk, and
> spindles where no other I/O gets in the way of the data I/O, then
> it can be handy. It does sound like something a database might
> like to use.
For MySQL, with InnoDB tables (the on-disk ones with transactions etc)
keeps one (or n) big data file(s) that grows dynamically (or you can
statically allocate them in chunks) - typical grow size is 5 or 10MB.
ideally, the ibdata files (and *especially* the ib_logfiles) would be
contiguous on disk (and close to each other on disk).
fsync performance is much more important for innodb (for transaction
throughput). XFS is slower than ext3 in this regard (from benchmarks
i've run*, data less than physical mem size).
for myisam tables, which don't grow by so much (handfuls of kilobytes),
and have several files per table (MYD data file, MYI index file) - all
tables for a database are in the same directory (usually, users can
configure this). The story becomes trickier here (many files growing).
XFS does as good or better than ext3.
MyISAM also doesn't explicitly sync (so with a lot of inserts, you get
only one allocation request).
NDB (Cluster) keeps all data in memory and checkpoints to disk (keeping
several around). currently, i don't think we use direct io (we should) -
when i have a spare minute or three i'll add the flag and see what
happens.
[*] Can post full benchmark results (mysql-bench), instructions on how
to duplicate etc
--
Stewart Smith, Software Engineer
MySQL AB, www.mysql.com
Office: +14082136540 Ext: 6616
VoIP: 6616@xxxxxxxxxxxxxxxx
Mobile: +61 4 3 8844 332
Jumpstart your cluster:
http://www.mysql.com/consulting/packaged/cluster.html
signature.asc
Description: This is a digitally signed message part
|