From: "K.S. Bhaskar" <ks.bhaskar@fnis.com>
To: "Alan D. Brunelle" <Alan.Brunelle@hp.com>
Cc: Jeff Moyer <jmoyer@redhat.com>,
James Bottomley <James.Bottomley@HansenPartnership.com>,
linux-scsi <linux-scsi@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-fsdevel@vger.kernel.org
Subject: Re: Enterprise workload testing for storage and filesystems
Date: Fri, 21 Nov 2008 11:42:41 -0500 [thread overview]
Message-ID: <4926E501.9010802@fnis.com> (raw)
In-Reply-To: <4926DF63.1030107@hp.com>
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.
_____________
next prev parent reply other threads:[~2008-11-21 16:42 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-17 22:47 Enterprise workload testing for storage and filesystems James Bottomley
2008-11-20 21:37 ` Jeff Moyer
2008-11-21 15:59 ` K.S. Bhaskar
2008-11-21 16:18 ` Alan D. Brunelle
2008-11-21 16:42 ` K.S. Bhaskar [this message]
2008-11-21 4:42 ` Grant Grundler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4926E501.9010802@fnis.com \
--to=ks.bhaskar@fnis.com \
--cc=Alan.Brunelle@hp.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=jmoyer@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).