[lttng-dev] LTTNG question (Threads spawned by LTTNG)

[Jonathan Rajotte-Julien]

On Tue, Oct 03, 2017 at 08:33:13AM +0000, Andreas Indlekofer wrote:
>    Hello all,
> 
>    Our application consists of several services running in their own Linux
>    process. Now we see that every process contains two threads with the same
>    name as the parent process and the ending ‘-ust’. We are wondering why we
>    have these threads, what is the purpose of the threads and did they
>    influence the runtime behavior in case we do no tracing.

Those two thread are responsible for communication with lttng-sessiond. One for
global sessiond and one for local sessiond. If the binary is a setuid binary no thread
for local sessiond will be spawned. This is to accommodate scenario where there is a
user defined lttng-sessiond and a global one. Both will wait for wake up based
on shared memory futexes. Hence if no sessiond is present the only runtime
behavior influence is the spawning of the threads and the cleanup at the end of
the application. If a sessiond is present, the ust thread will activate and will
perform registrations and subsequent actions required for tracing based on
instruction passed to lttng-sessiond.

> 
>    Additionally we see atleast ten lttng-sessiond threads. Also here we have

client_thread:
    Manage clients (lttng cli/liblttng-ctl) requests.

kernel_thread:
    Manage events (CPU hotplug) relevant to kernel tracing.

apps_thread:
    React on apps events for lttng-sessiond to apps communication channel.

apps_notify_thread:
    React on apps events for apps to lttng-sessiond communication channel.

reg_apps_thread:
    Fast apps registration acknowledgement and queue apps for full registration
    in dispatch_thread.

dispatch_thread:
   Differed and full registration of apps.

health_thread:
    Monitors the overall health of the sessiond. The health
    status can be queried via lttng_health_query from liblttng-ctl.

ht_cleanup_thread:
    Performs RCU hash table cleanup.

agent_reg_thread:
    Responsible for agent registration and management (Java, Python tracing).

load_session_thread:
    Short lived thread used at lttng-sessiond start to load automatic session
    (see lttng save/load).

There is also consumerd management threads. The number will vary depending if we
support x86, x86/_64 and/or kernel tracing.

>    the question, why we have ten threads, what is the purpose and do they
>    influence the runtime behavior, if we have no tracing active.

Most of those threads are idle, waiting for events, if no tracing/interaction is
happening. Even when tracing the sessiond is mostly idle. The notable influence will
be at application startup with the registration phase. Most of the work of
tracing is performed in lttng-consumerd. If no tracing is activated, the
apps will register to lttng-sessiond but since no session is active not much
will happen afterwards both on lttng-sessiond and lttng-consumerd side.

Note that this is a quick explanation and might not be absolutely accurate. I'm
sure someone will step in if something here is wrong.

Cheers

> 
>     
> 
>    Best regards,
> 
>    Andreas

> _______________________________________________
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev


-- 
Jonathan Rajotte-Julien
EfficiOS