[Lustre-discuss] OSS Service Thread Count

[Brian J. Murrell]

On Mon, 2009-01-26 at 00:01 -0500, Oleg Drokin wrote:
> Hello!

In addition to Oleg's suggestions...

> Essentially what is happening is your drives are only able to sustain  
> certain
> amount of parallel i/o activity before degrading the performance due  
> to all the
> seeking going on. Ideally you need to set the number of ost threads to  
> this
> number, but this is complicated by the fact that different workloads  
> (as in
> i/o sizes) result in different parallel streams the drives can handle.

Understanding the performance of your storage hardware is exactly why we
always recommend profiling it with the lustre iokit -- ideally, prior to
deployment of the filesystem.

The obdfilter-survey specifically profiles the overall throughput of
your hardware while the sgpdd-survey profiles individual disks.  The
former is supposed to be usable, non-destructively, on an existing
fileystem, however the latter is absolutely destructive and should not
be run anywhere you want preserve existing data.

Now, I mention the non-destructive nature of obdfilter-survey with
trepidation.  That is it's intent, and for the number of times I have
used it has proven to be as advertised, however I am doubtful that that
specific aspect gets regularly tested by our QA department and as such
there is always a possibility of a bug sneaking in which voids that
intent.  Proceed with caution.

Anyway, the obdfilter-survey simply sends ranges of workloads to your
OSTs, varying in thread counts and I/O sizes.  When it's all done it
gives you a (figurative, or graphic if you use the plot scripts on teh
data) picture of the performance abilities of your storage hardware and
will show you where the saturation points are.

b.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.lustre.org/pipermail/lustre-discuss-lustre.org/attachments/20090126/1d0451cb/attachment.pgp>