On Fri, Jul 26, 2013 at 3:29 PM, Martin Ünsal <[email protected]> wrote: > Hi all, > > I am a new lttng-ust user. I would like to leave tracepoints compiled into > production code. I have verified that inactive tracepoints have extremely > low overhead, but I am concerned about startup time and > LTTNG_UST_REGISTER_TIMEOUT. Our typical use case is that we are not tracing > and there is no lttng-sessiond, we enable tracing only in development or QA. > > The specific questions: > > 1) What scenarios might the timeout come into play? I have tested with and > without lttng-sessiond running and I have seen no more than 10ms overhead > during app startup caused by lttng. That's no problem, but if there is some > unforeseen scenario where I introduce 3s overhead I am in a world of hurt! >
This timeout is in place because the applications' registration to the session daemon may take a long time if a lot of instrumented applications are launched simultaneously. The only time I see the launch time affected on the order of seconds, on my development machine, is when performing stress tests; e.g. launching a couple of thousands instrumented applications at once. Only you know if that's a realistic load you may encounter. > 2) If I set LTTNG_UST_REGISTER_TIMEOUT=0, what scenario would this fail and > how would it fail? (Silently or detectably?) > It will fail if the registration request cannot be served right-away. The registration failing only means that the events won't be saved. It should not impact your application in any other way. I don't know how you could easily detect the registration's outcome from your application, though... I can certainly see how that would be useful. The work-around I can propose is to use the lttng-ctl API to probe the session daemon from your application. You could use the lttng_list_sessions(), lttng_list_channels() and lttng_list_events() functions to check all enabled events for your application's PID. Have a look at the "lttng.h" header (lttng-tools) and let me know if you need further clarifications. > Actually I think these are more or less the same question viewed from two > different angles. > > Thanks much. BTW I should say, I've been doing coordinated userspace and > kernel tracing for performance issues in Linux for many, many years using a > variety of homegrown tools and LTTng is fantastic, just the right feature > set and excellent performance. It's what I wish I'd built. :) We're always looking for contributors! :-) Regards, Jérémie > > Martin > > > _______________________________________________ > lttng-dev mailing list > [email protected] > http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev > -- Jérémie Galarneau EfficiOS Inc. http://www.efficios.com _______________________________________________ lttng-dev mailing list [email protected] http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
