Re: Random file I/O regressions in 2.6

[Peter Zaitsev]

On Thu, 2004-05-06 at 01:43, Andrew Morton wrote:

> 
> One thing I note about this test is that it generates a huge number of
> inode writes.  atime updates from the reads and mtime updates from the
> writes.  Suppressing them doesn't actually make a lot of performance
> difference, but that is with writeback caching enabled.  I expect that with
> a writethrough cache these will really hurt.

Perhaps.  By the way is there a way to disable update time modification
as well ?  It would make quite a good sense for partition used for
Database needs - you do not need last modification time in most cases.

> 
> The test uses 128 files, which seems excessive.  I assume that four or
> eight files is a more likely real-life setup, and in theis case the
> atime/mtime update volume will be proportionately less.

Actually both single (or very few) files and large amount of files are
practical setup. In MySQL 4.1 we have the option to store each Innodb
table in its own file, which will mean scattered random IO to many files
for OLTP workloads. 

You might think 128 actively used tables are still to much, but
practically we see even larger numbers - some customers partition data,
creating huge number of tables with same structure, for example
table-per customer.



-- 
Peter Zaitsev, Senior Support Engineer
MySQL AB, www.mysql.com



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/