Re: Enterprise workload testing for storage and filesystems

[K.S. Bhaskar]

On 11/21/2008 11:18 AM, Alan D. Brunelle wrote:
> K.S. Bhaskar wrote:

[KSB2] <...snip...>

> Thanks for additional feedback Bhaskar - I've been playing with this
> on-and-off the last couple of days trying to stress one testbed (16 way
> AMD, 128GB RAM, two P800 Smart Arrays (48 disks total put into a single
> LVM2/DM volume)). I've been able to get the I/O subsystem 100% utilized,
> but in so doing really didn't stress the system (something like 80-90%
> idle).
>
> In order to stress the whole system, it sounds like it _may_ be better
> to use 48 separate file systems on 48 separate platters (each with its
> own DB)? Or are there other knobs to play with to get more of the system
> involved besides the I/O? Is it a good idea to separate the journals
> from the DB (separate FS/platter)?

[KSB2] The intent of io_thrash is to stress the IO subsystem.  So, I am 
not at all surprised that CPU and memory were not stressed.

With the 48 platters on your system, perhaps consider creating 4 logical 
volumes each striped across 12 physical volumes.  Try 8 databases, with 
each logical volume having two databases and journal files for two 
databases that reside on different file systems.

In the real world, yes one would separate each journal file from its 
database file, at least putting them on separate platters, because if 
the journal platters, disk controller, or file system croak, you still 
have the database, and if the database underpinnings die, the database 
is recoverable from a backup and the journal file.  One aims to get 
maximum separation from the database and its journal file.

If you want to simulate an application that produces a more balanced 
load, perhaps you can set %ioUnderLock to 0 and modify io_thrash to do 
some compute intensive task (like fill a large block of memory with 
pseudo random numbers) before each IO operation.  You would probably 
want to increase the number of processes so that the IO subsystem 
continues to be driven hard.

Regards
-- Bhaskar

_____________

The information contained in this message is proprietary and/or confidential. If you are not the 
intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, 
distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, 
please be aware that any message addressed to our domain is subject to archiving and review by 
persons other than the intended recipient. Thank you.
_____________
--
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/