From: Eric Barton <eric.barton@oracle.com>
To: lustre-devel@lists.lustre.org
Subject: [Lustre-devel] Lustre RPC visualization
Date: Tue, 1 Jun 2010 16:58:48 +0100 [thread overview]
Message-ID: <001601cb01a3$546c93d0$fd45bb70$@barton@oracle.com> (raw)
In-Reply-To: <4C04F3F0.9040708@oracle.com>
I'd really like to see how vampire handles _all_ the trace data
we can throw at it. If 600 clients is a pain, how bad will it
be at 60,000?
What in particular makes collecting traces from all the clients
+ servers hard? How can/should we automate it or otherwise make
it easier?
Cheers,
Eric
> -----Original Message-----
> From: di.wang [mailto:di.wang at oracle.com]
> Sent: 01 June 2010 12:50 PM
> To: Robert Read
> Cc: Michael Kluge; Eric Barton; Galen M. Shipman
> Subject: Re: [Lustre-devel] Lustre RPC visualization
>
> Hello,
>
> IMHO, just run IOR with whatever parameters, and get rpctrace
> log(probably only enable rpctrace) from 1 OST and some of clients
> (probably 2 is enough).
> Note: please make sure these 2 clients did communicate the OST during
> the IOR.
>
> Michael, I do not think you need all the trace logs from the clients. right?
>
> Robert
>
> If there are available time slots for this test on Hyperion, who can
> help to get these logs?
>
> Thanks
> Wangdi
>
> Robert Read wrote:
> > What should I run then? Do have scripts to capture this?
> >
> > robert
> >
> > On May 31, 2010, at 2:39 , Michael Kluge wrote:
> >
> >> Hi Robert,
> >>
> >> 600 is a nice number. Plus the traces from the server an I am happy.
> >>
> >>
> >> Michael
> >>
> >> Am 28.05.2010 um 17:53 schrieb Robert Read:
> >>
> >>>
> >>> On May 28, 2010, at 4:09 , di.wang wrote:
> >>>
> >>>> Hello, Michael
> >>>>
> >>>>> One good news: The Feature that Vampir can show something like a heat
> >>>>> map (Eric asked about this) comes back with the release at ISC. It is
> >>>>> now called "performance radar". It can produce a heat map for a
> >>>>> counter
> >>>>> and does some other things as well. I could send a picture around, but
> >>>>> need at first an bigger trace (more hosts generating traces in
> >>>>> parallel).
> >>>>>
> >>>> Right now I do not have big clusters available to generate the trace.
> >>>> I will see what I can do here.
> >>>
> >>> If ~600 clients is big enough we could generate that on Hyperion.
> >>>
> >>> robert
> >>>
> >>>>
> >>>> Thanks
> >>>> WangDi
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>> ------------------------------------------------------------------------
> >>>>>
> >>>>> _______________________________________________
> >>>>> Lustre-devel mailing list
> >>>>> Lustre-devel at lists.lustre.org <mailto:Lustre-devel@lists.lustre.org>
> >>>>> http://lists.lustre.org/mailman/listinfo/lustre-devel
> >>>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >> --
> >>
> >> Michael Kluge, M.Sc.
> >>
> >> Technische Universit?t Dresden
> >> Center for Information Services and
> >> High Performance Computing (ZIH)
> >> D-01062 Dresden
> >> Germany
> >>
> >> Contact:
> >> Willersbau, Room WIL A 208
> >> Phone: (+49) 351 463-34217
> >> Fax: (+49) 351 463-37773
> >> e-mail: michael.kluge at tu-dresden.de <mailto:michael.kluge@tu-dresden.de>
> >> WWW: http://www.tu-dresden.de/zih
> >>
> >
next prev parent reply other threads:[~2010-06-01 15:58 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <000c01cae6ee$1d4693d0$57d3bb70$@barton@oracle.com>
2010-04-29 1:25 ` [Lustre-devel] (no subject) di.wang
2010-04-29 1:49 ` Andreas Dilger
2010-04-29 2:04 ` di.wang
2010-04-29 4:48 ` [Lustre-devel] Lustre RPC visualization Michael Kluge
[not found] ` <4BD9CF75.8030204@oracle.com>
2010-05-03 8:41 ` Michael Kluge
2010-05-03 13:20 ` Andreas Dilger
2010-05-03 18:10 ` Michael Kluge
2010-05-03 18:57 ` Robert Read
2010-05-03 18:58 ` di.wang
2010-05-03 19:32 ` Michael Kluge
2010-05-03 19:52 ` di.wang
2010-05-03 20:04 ` Michael Kluge
2010-05-16 9:29 ` Michael Kluge
2010-05-16 13:12 ` Eric Barton
2010-05-17 4:52 ` Michael Kluge
2010-05-17 3:24 ` Andrew Uselton
2010-05-17 5:53 ` Michael Kluge
[not found] ` <009101caf4f9$67e1dd50$37a597f0$%barton@oracle.com>
2010-05-17 3:39 ` Shipman, Galen M.
2010-05-17 5:59 ` Michael Kluge
2010-05-25 12:03 ` Michael Kluge
[not found] ` <4BFC7177.9000808@oracle.com>
2010-05-28 14:54 ` Michael Kluge
[not found] ` <4BFFA456.7030502@oracle.com>
[not found] ` <C671351E-110C-4D2C-B216-4E8BE23A943A@oracle.com>
[not found] ` <1FF3D25F-3369-462E-9651-62D56319612A@tu-dresden.de>
[not found] ` <D29ED098-3DEB-4AF4-AA68-B52B4E2BF5EA@oracle.com>
[not found] ` <4C04F3F0.9040708@oracle.com>
[not found] ` <001601cb01a3$546c93d0$fd45bb70$%barton@oracle.com>
2010-06-01 12:12 ` di.wang
2010-06-01 17:03 ` Andreas Dilger
2010-06-01 19:39 ` Michael Kluge
2010-06-16 8:46 ` Michael Kluge
2010-06-16 14:50 ` Andreas Dilger
2010-06-17 14:02 ` Michael Kluge
[not found] ` <4169315E-9A94-4430-8970-92068222EF15@oracle.com>
2010-06-20 20:44 ` Michael Kluge
2010-06-22 15:12 ` Michael Kluge
2010-06-23 10:29 ` Alexey Lyashkov
2010-06-23 11:50 ` Michael Kluge
2010-06-23 12:09 ` Alexey Lyashkov
2010-06-23 12:38 ` Michael Kluge
2010-06-23 15:55 ` Andreas Dilger
2010-06-24 8:01 ` Michael Kluge
2010-06-01 15:58 ` Eric Barton [this message]
2010-09-22 13:46 ` Michael Kluge
2010-09-22 18:28 ` Andreas Dilger
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='001601cb01a3$546c93d0$fd45bb70$@barton@oracle.com' \
--to=eric.barton@oracle.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.