Re: Enterprise workload testing for storage and filesystems

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux