Hi all, I have successfully tested lmt on Lustre 1.4.6 and I have some comments tu say about the help. Both "lmtd --help" and "lmtcollect --help" seems to be out of date, e.g. the lmtd help did not mention -c option and lmtcollect help did not mention -c, -t and -x options. Moreover the "lmtd --help" output says that the default listen port of lmtd is 50534 which in fact is 50538. In addition, the lmt project on sourceforge don''t seems to be active. Have you plan to use the features provided by sourceforge, like tracking for example ? tia Jerome Marchand
Hi Jerome, Sorry for the delay responding. lmt is used internally at LLNL to monitor our lustre clusters. We put the tool out on sourceforge for others to try but I don''t believe there has been much interest to stimulate effort on our part ot keep SF up to date or take advantage of trackers or the source repo. There have been a few changes since the 1.17 SF release which we''re rolling together, along with the --help changes you pointed out, into a new release that we''ll put out shortly after testing. I think we''re open to doing more on SF if there is interest. Jim On Thu, 19 Oct 2006 jerome.marchand@ext.bull.net wrote:> Hi all, > > I have successfully tested lmt on Lustre 1.4.6 and I have some comments tu > say about the help. Both "lmtd --help" and "lmtcollect --help" seems to be > out of date, e.g. the lmtd help did not mention -c option and lmtcollect help > did not mention -c, -t and -x options. Moreover the "lmtd --help" output says > that the default listen port of lmtd is 50534 which in fact is 50538. > > In addition, the lmt project on sourceforge don''t seems to be active. Have > you plan to use the features provided by sourceforge, like tracking for > example ? > > tia > Jerome Marchand > > _______________________________________________ > Lustre-discuss mailing list > Lustre-discuss@clusterfs.com > https://mail.clusterfs.com/mailman/listinfo/lustre-discuss >
I know that out here there is a lot of interest of getting lmt (and xwatch-lustre) to keep track of historical information (wouldn''t it be nice if xwatch-lustre showed a real-time updated graph of current transfer rates). On Thu, 2006-10-26 at 11:29 -0700, Jim Garlick wrote:> Hi Jerome, > > Sorry for the delay responding. lmt is used internally at LLNL > to monitor our lustre clusters. We put the tool out on sourceforge > for others to try but I don''t believe there has been much interest > to stimulate effort on our part ot keep SF up to date or take advantage > of trackers or the source repo. > > There have been a few changes since the 1.17 SF release which we''re > rolling together, along with the --help changes you pointed out, > into a new release that we''ll put out shortly after testing. > I think we''re open to doing more on SF if there is interest. > > Jim > > On Thu, 19 Oct 2006 jerome.marchand@ext.bull.net wrote: > > > Hi all, > > > > I have successfully tested lmt on Lustre 1.4.6 and I have some comments tu > > say about the help. Both "lmtd --help" and "lmtcollect --help" seems to be > > out of date, e.g. the lmtd help did not mention -c option and lmtcollect help > > did not mention -c, -t and -x options. Moreover the "lmtd --help" output says > > that the default listen port of lmtd is 50534 which in fact is 50538. > > > > In addition, the lmt project on sourceforge don''t seems to be active. Have > > you plan to use the features provided by sourceforge, like tracking for > > example ? > > > > tia > > Jerome Marchand > > > > _______________________________________________ > > Lustre-discuss mailing list > > Lustre-discuss@clusterfs.com > > https://mail.clusterfs.com/mailman/listinfo/lustre-discuss > > > > _______________________________________________ > Lustre-discuss mailing list > Lustre-discuss@clusterfs.com > https://mail.clusterfs.com/mailman/listinfo/lustre-discuss >-- Makia Minich <minich@ornl.gov> National Center for Computation Science Oak Ridge National Laboratory Phone: 865.574.7460
OK, good to know! There is a move afoot here to insert a database between lmtcollect and xwatch-lustre and to add the ability to roll back time and plot graphs just as you suggest. We''re currently gathering requirements for this effort, so now is a good time to request features. Jim On Thu, 26 Oct 2006, Minich, Makia wrote:> I know that out here there is a lot of interest of getting lmt (and > xwatch-lustre) to keep track of historical information (wouldn''t it be > nice if xwatch-lustre showed a real-time updated graph of current > transfer rates). > > On Thu, 2006-10-26 at 11:29 -0700, Jim Garlick wrote: >> Hi Jerome, >> >> Sorry for the delay responding. lmt is used internally at LLNL >> to monitor our lustre clusters. We put the tool out on sourceforge >> for others to try but I don''t believe there has been much interest >> to stimulate effort on our part ot keep SF up to date or take advantage >> of trackers or the source repo. >> >> There have been a few changes since the 1.17 SF release which we''re >> rolling together, along with the --help changes you pointed out, >> into a new release that we''ll put out shortly after testing. >> I think we''re open to doing more on SF if there is interest. >> >> Jim >> >> On Thu, 19 Oct 2006 jerome.marchand@ext.bull.net wrote: >> >>> Hi all, >>> >>> I have successfully tested lmt on Lustre 1.4.6 and I have some comments tu >>> say about the help. Both "lmtd --help" and "lmtcollect --help" seems to be >>> out of date, e.g. the lmtd help did not mention -c option and lmtcollect help >>> did not mention -c, -t and -x options. Moreover the "lmtd --help" output says >>> that the default listen port of lmtd is 50534 which in fact is 50538. >>> >>> In addition, the lmt project on sourceforge don''t seems to be active. Have >>> you plan to use the features provided by sourceforge, like tracking for >>> example ? >>> >>> tia >>> Jerome Marchand >>> >>> _______________________________________________ >>> Lustre-discuss mailing list >>> Lustre-discuss@clusterfs.com >>> https://mail.clusterfs.com/mailman/listinfo/lustre-discuss >>> >> >> _______________________________________________ >> Lustre-discuss mailing list >> Lustre-discuss@clusterfs.com >> https://mail.clusterfs.com/mailman/listinfo/lustre-discuss >> > -- > Makia Minich <minich@ornl.gov> > National Center for Computation Science > Oak Ridge National Laboratory > Phone: 865.574.7460 >
On Thursday 26 October 2006 20:29, Jim Garlick wrote:> Hi Jerome, > > Sorry for the delay responding. lmt is used internally at LLNL > to monitor our lustre clusters. We put the tool out on sourceforge > for others to try but I don''t believe there has been much interest > to stimulate effort on our part ot keep SF up to date or take advantage > of trackers or the source repo. > > There have been a few changes since the 1.17 SF release which we''re > rolling together, along with the --help changes you pointed out, > into a new release that we''ll put out shortly after testing. > I think we''re open to doing more on SF if there is interest.We use lmt and would love to see it evolve. Top of our wishlist would probably be 1.6 support and some kind of db/graphing functionality. Thanks for a nice piece of software, Peter> Jim-- ------------------------------------------------------------ Peter Kjellstr?m | National Supercomputer Centre | Sweden | http://www.nsc.liu.se -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mail.clusterfs.com/pipermail/lustre-discuss/attachments/20061027/71b7d5ed/attachment.bin
Just to let you know we use LMT too and find it very useful - our production staff particularly like being able to easily check their render throughput. Graphing and historical data would certainly be nice. We hacked it to work with 1.6 quite easily so that shouldn''t be a difficult feature addition. Regards, Daire> On Thursday 26 October 2006 20:29, Jim Garlick wrote: >> Hi Jerome, >> >> Sorry for the delay responding. lmt is used internally at LLNL >> to monitor our lustre clusters. We put the tool out on sourceforge >> for others to try but I don''t believe there has been much interest >> to stimulate effort on our part ot keep SF up to date or take advantage >> of trackers or the source repo. >> >> There have been a few changes since the 1.17 SF release which we''re >> rolling together, along with the --help changes you pointed out, >> into a new release that we''ll put out shortly after testing. >> I think we''re open to doing more on SF if there is interest. > > We use lmt and would love to see it evolve. Top of our wishlist would probably > be 1.6 support and some kind of db/graphing functionality. > > Thanks for a nice piece of software, > Peter > >> Jim > >
Jim, On 2006-10-27, at 6:04 , Jim Garlick wrote:> OK, good to know! > > There is a move afoot here to insert a database between lmtcollect > and xwatch-lustre and to add the ability to roll back time and plot > graphs just as you suggest. We''re currently gathering requirements > for this effort, so now is a good time to request features. > > JimWould Livermore consider gathering requirements from the Lustre community and shifting your development efforts to the SourceForge site? It seems there is much interest, and you may even benefit from community contribution. Peter
On Wed, 1 Nov 2006, Peter Bojanic wrote:> Jim, > > On 2006-10-27, at 6:04 , Jim Garlick wrote: > >> OK, good to know! >> >> There is a move afoot here to insert a database between lmtcollect >> and xwatch-lustre and to add the ability to roll back time and plot >> graphs just as you suggest. We''re currently gathering requirements >> for this effort, so now is a good time to request features. >> >> Jim > > Would Livermore consider gathering requirements from the Lustre community and > shifting your development efforts to the SourceForge site? It seems there is > much interest, and you may even benefit from community contribution. > > Peter >Hi Peter, The short answer is yes. The long answer is we let the lmt SF site atrophy (sorry about that), but based on comments here, we''ve fixed the one bug that''s been reported, added some internal maintenance changes, and have lmt-1.20 ready to push up to SF (any day now). We will endeavor to keep SF alive as long as there are people interested in the software. If there is demand (in the form of lively discussion, patches, etc), we would be OK with switching to more of a distributed development model, using SF mailman lists, trackers, public svn, etc.. Internally, we''re talking about lmt-2.0 and would like to take any community comments into account as we plan it. So far we''ve heard agreement that history + graphs are good and lustre-1.6 support is needed. If there are other desirable features, we like to hear about them. So far our discussions have lmtcollect feeding each sample to mysql, and the client connecting to db''s (one per file system) using the mysql API. Initially the GUI would look like xwatch-lustre, but eventually we would provide the ability to show historical views, plot individual values (like I/O rates) over time, generate reports, etc.. We want to design the system so the schema can change (new rows, etc) and the GUI will automatically reflect those changes. We are thinking about an events table where asynchronous events like LBUG''s, crashes, etc could be logged and then correlated with the performance and health data. We think we will probably store the lustre cluster configuration in the database statically rather than have it read XML as we do now or query the MGS as it would need to do in lustre-1.6. That''s the current state of our thinking. The plan going forward is to produce an informal design document before we start the work. I will try to get that posted here for comment when we have it. Meanwhile, please send on any thoughts! Jim