[prev in list] [next in list] [prev in thread] [next in thread] 

List:       lustre-devel
Subject:    [Lustre-devel] Lustre RPC visualization
From:       Michael.Kluge () tu-dresden ! de (Michael Kluge)
Date:       2010-06-24 8:01:14
Message-ID: 44E9F0A8-5850-4FAA-992C-2C57D4F54AEE () tu-dresden ! de
[Download RAW message or body]

> While Alexey's comment is correct, in that there can be multiple Lustre client \
> mounts on a single node, this is generally only used for testing.  For client \
> connections the UUID is just a random value like \
> "f4726b1e-f7eb-479f-b163-784ea45adf32", so using the NID is much more useful to the \
> viewer in the vast majority of cases.

Well, what I can do with OTF and Vampir is to use a process hierarchy. So for each \
NID I can have a couple of UUID as 'child processes'. Like the way one looks at \
hybrid MPI & OpenMP programs. Where we have MPI processes and treat OpenMP threads as \
child processes.

> If you wanted to distinguish the multiple mounts from a single client it would be \
> best to just do this internally by tracking both the NID and the UUID, but only \
> printing the NID on the output.  For the rare case where requests have the same NID \
> but a different UUID you could show this as "NID:2", "NID:3" or similar.  That \
> preserves the distinction between client connections, while not making the output \
> completely useless.

Yes, that fits into the statement above.

> Even better than plain numeric NIDs would be to do IP->hostname conversion for the \
> case of TCP and IB LNDs, if this works.

Well, typically I only have the debug log. Which might be incomplete. I don't think I \
have something that can do this conversion reliably?


Michael


> > Am 23.06.2010 um 12:29 schrieb Alexey Lyashkov:
> > 
> > > I think better to use client UUID instead of NID as client identification. \
> > > Because in your's case - you can't separate info from two clients which run on \
> > > same node. 
> > > 
> > > On Jun 22, 2010, at 19:12, Michael Kluge wrote:
> > > 
> > > > The remaining problems of the counter calculations have been fixed. There is \
> > > > a screenshot attached showing some values. The code is in a gforge server \
> > > > that we operate here in Dresden (gforge.zih.tu-dresden.de). The converter \
> > > > runs on Linux and on MAC OS X and you need Vampir to take a look at the OTF \
> > > > trace file. 
> > > > Eric, Galen, for the moment I think I am done with the stuff I promised you \
> > > > at LUG this year? Are there any more ideas? 
> > > > 
> > > > Michael
> > > > 
> > > > 
> > > > 
> > > > <lustre3.png>
> > > > 
> > > > 
> > > > 
> > > > 
> > > > http://lists.lustre.org/mailman/listinfo/lustre-devel
> > > 
> > > 
> > > 
> > > --------------------------------------
> > > Alexey Lyashkov
> > > alexey.lyashkov at clusterstor.com
> > > 
> > > 
> > > 
> > > 
> > 
> > 
> > -- 
> > 
> > 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
> > WWW:    http://www.tu-dresden.de/zih
> > 
> > _______________________________________________
> > Lustre-devel mailing list
> > Lustre-devel at lists.lustre.org
> > http://lists.lustre.org/mailman/listinfo/lustre-devel
> 
> 
> Cheers, Andreas
> --
> Andreas Dilger
> Lustre Technical Lead
> Oracle Corporation Canada Inc.
> 
> 


-- 

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
WWW:    http://www.tu-dresden.de/zih

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20100624/77e1f513/attachment.htm>



[prev in list] [next in list] [prev in thread] [next in thread]