From: Kienan Stewart via lttng-dev <lttng-dev@lists.lttng.org>
To: lttng-dev@lists.lttng.org, Zach.Kramer@cognex.com
Subject: Re: [lttng-dev] LTTng enable-event performance issue during active session
Date: Thu, 5 Oct 2023 18:04:04 -0400 [thread overview]
Message-ID: <f0437833-964c-4aee-a52b-e79fd89540fc@efficios.com> (raw)
In-Reply-To: <SN6PR06MB426922F9DBACE81D0C6B66A591C3A@SN6PR06MB4269.namprd06.prod.outlook.com>
Hi Zach
apologies for the delay in replying to your question.
On 2023-09-26 08:27, Kramer, Zach via lttng-dev wrote:
> Hi,
>
> I am observing a performance issue with regards to enabling events while
> a session is active and was wondering if this is expected.
>
> LTTng versions:
>
> * lttng-tools: 2.13.9
> * lttng-ust: 2.13.6
>
> Steps to reproduce:
>
> 1. Ensure many userspace tracepoints are available in `lttng list -u`
> e.g. 100
> 2. Create a new session
> 3. Start session
> 4. Enable new events on session
>
> The time it takes to enable each new event has increasing cost e.g.
>
> 1. Event 1: 1ms
> 2. Event 100: 15ms
> 3. Event 1000: 150ms
> 4. àin total about 1.5 minutes to enable 1000 events
>
> If either:
>
> 1. No userspace tracepoints are available
> 2. Or session is not started until /after /the events are enabled
>
> Then the time it takes to enable new events is constant (e.g. 1ms).
>
> Below is a bash script demonstrating this behavior:
>
> # Pre-requisite: have many userspace tracepoints available
>
> lttng create foo
>
> lttng enable-channel -u -s foo bar
>
> lttng start foo
>
> total_t1=$(date +%s%3N);
>
> for i in {1..100}
>
> do
>
> t1=$(date +%s%3N);
>
> lttng enable-event -u lttng_iter_$i -s foo -c bar > /dev/null
>
> t2=$(date +%s%3N);
>
> echo "Event #$i took $((t2-t1)) ms"
>
> done
>
> total_t2=$(date +%s%3N);
>
> echo "----------------------------------------------------"
>
> echo "Enabling events on active session took $((total_t2-total_t1)) ms"
>
> echo "----------------------------------------------------"
>
> lttng destroy foo
>
> lttng create foo
>
> lttng enable-channel -u -s foo bar
>
> total_t1=$(date +%s%3N);
>
> for i in {1..100}
>
> do
>
> t1=$(date +%s%3N);
>
> lttng enable-event -u lttng_iter_$i -s foo -c bar > /dev/null
>
> t2=$(date +%s%3N);
>
> echo "Event #$i took $((t2-t1)) ms"
>
> done
>
> total_t2=$(date +%s%3N);
>
> echo "----------------------------------------------------"
>
> echo "Enabling events on inactive session took $((total_t2-total_t1)) ms"
>
> echo "----------------------------------------------------"
>
> lttng destroy foo
>
> Is this reproducible for you? Any insight is appreciated.
>
I'm able to reproduce what you're seeing, and it's not completely
unexpected based on my understanding of the architecture of lttng.
When a session is active and an event rule is enabled/disabled, the
sessiond will notify each of the registered applications of the event
rule state changes. This communication is going through either unix or
tcp sockets, and that portion of the protocol seems to struggle with
many small changes as the protocol to communicate the changes doesn't
support batching.
Enabling multiple events in a single call reduces some of the overhead,
but the changes will still be communicated serially. This means a single
call activating thousands events can still take a long time to process
(eg. `lttng enable-event -s foo -c bar -u tp0,tp1,...,tpN`)
Using glob patterns or `--all` will be significantly faster as the UST
applications can digest those types of event rule changes with a single
set of messages. In cases where you want most but not all events,
flipping the logic to enable "*" but add events or patterns to omit with
"--exclude" is going to be a better strategy.
Do you have cases where you need to activate many of events but which
couldn't be covered by using glob patterns and/or exclusions?
thanks,
kienan
> Many thanks,
>
> Zach
>
>
> _______________________________________________
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
next prev parent reply other threads:[~2023-10-05 22:04 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-26 12:27 Kramer, Zach via lttng-dev
2023-10-05 22:04 ` Kienan Stewart via lttng-dev [this message]
2023-10-06 16:12 ` Kienan Stewart via lttng-dev
2023-10-09 10:29 ` [lttng-dev] [EXTERNAL] " Kramer, Zach via lttng-dev
2023-10-17 15:39 ` Kienan Stewart via lttng-dev
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=f0437833-964c-4aee-a52b-e79fd89540fc@efficios.com \
--to=lttng-dev@lists.lttng.org \
--cc=Zach.Kramer@cognex.com \
--cc=kstewart@efficios.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox