All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Seger <Mark.Seger@hp.com>
To: lustre-devel@lists.lustre.org
Subject: [Lustre-devel] LustreFS performance
Date: Tue, 10 Mar 2009 11:07:36 -0400	[thread overview]
Message-ID: <49B68238.4000901@hp.com> (raw)
In-Reply-To: <49B67B91.9080605@cray.com>


>>> **** Statistics ****
>>>
>>> During all the tests the following is supposed to be running on all  
>>> the servers:
>>> 1) vmstat
>>> 2) iostat, if there is some disk activity.
>>> smth else?
>>>       
>> I would propose either LLNL's LMT or HP's collectl, which both also
>> collect Lustre stats.  Those both provide more information than the
>> above, and having the IO/CPU load correlated to Lustre RPC counts is
>> very useful.
>>     
>
> It would be great if we could standardize on a set of tools for performance 
> issues. I've got to think a set of tools like this would make it easier for 
> customer & partners to gather the correct data the first time.
>
> Cray has been using lstats, a package of scripts we got from Sun a while back. 
> We've added things like AT timeout and sar per-cpu usage to it (see bug 18574 
> att 22140 for complete set of scripts).
>
> I'm all for using collectl, but I think the requirements and setup for LMT makes 
>   it a tough sell. Does Sun have a set of customizations for collectl or does 
> the standard collectl collect enough information?
>   
My goal when I wrote collectl was to provide one-stop shopping for as 
much system performance data as seemed relevant and view lustre as only 
one of many data sources.  To that end, if you do a merge of all the 
data collected by the *stat utilities, sar, perfquery (for IB), many of 
the lustre stats (but not all) and maybe a few others you'll get closer 
to understanding what collectl can collect.  On the output side you can 
pick and choose what to display - when used interactively only those 
data elements are collected but when run as a daemon you can collect 
them all and replay the data as ofter as you like looking at different 
slices.

As for LMT I haven't played with it as my interests are in dealing with 
all data.  However, as an exercise left to the reader, there are a 
number of switches for changing collectl's display as well as --home 
which moves the cursor the terminal's home position before displaying 
the output, giving a display similar to the feel of top.  If you want to 
display what's happening to lustre and your disks, cpu, etc all at the 
same time on a refreshing display, --top is definitely the way to go.

And finally, if you want something totally different and are feeling 
creative, just write your own print routines in perl and tell collectl 
to use them with the --export switch.

-mark

  reply	other threads:[~2009-03-10 15:07 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3376C558-E29A-4BB5-8C4C-3E8F4537A195@sun.com>
     [not found] ` <02FEAA2B-8D98-4C2D-9CE8-FF6E1EB135A2@sun.com>
2009-03-02 17:04   ` [Lustre-devel] LustreFS performance Vitaly Fertman
2009-03-02 20:45     ` Andreas Dilger
2009-03-04 17:19       ` Oleg Drokin
2009-03-04 17:28         ` Jeff Darcy
2009-03-05 21:27           ` Andreas Dilger
2009-03-09  2:50             ` Oleg Drokin
2009-03-09  8:29               ` Andreas Dilger
2009-03-10 14:39       ` Nicholas Henke
2009-03-10 15:07         ` Mark Seger [this message]
2009-03-10 11:55     ` Mallik Ragampudi
2009-03-10 16:40       ` Vitaly Fertman
2009-03-19 19:34   ` [Lustre-devel] LustreFS performance (update) Vitaly Fertman
2009-03-19 20:16     ` Andrew C. Uselton
2009-03-20 13:15       ` Vitaly Fertman
2009-03-20  5:47     ` parinay kondekar
2009-03-24  0:34       ` Eric Barton

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=49B68238.4000901@hp.com \
    --to=mark.seger@hp.com \
    --cc=lustre-devel@lists.lustre.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.