[lttng-dev] Some confusion about cpu usage of the lttng-consumerd process
mathieu.desnoyers at efficios.com
Fri Nov 27 12:11:34 EST 2020
----- On Nov 27, 2020, at 11:04 AM, lttng-dev lttng-dev at lists.lttng.org wrote:
> Well we also want to know why! You will understand that albeit we develop lttng
> we do not always have a quick and easy answer to all problems. Performance
> related problem are always tricky.
> And we also have to keep in mind that we do not necessarily optimize for low-cpu
> usage on the lttng-consumerd side.
That being said, we did optimize for low-cpu usage of lttng-consumerd for use-cases
streaming to disk or to the network. However, the "live" mode was originally created
for use-cases where only a few events per second would be emitted, and no such
requirements were placed on performance. We can see today that its use has grown
much beyond the few events per seconds, but then in those use-cases the live mode
may not be the appropriate tool for the job then. We have introduced the "session
rotation" feature as a more efficient alternative to the live mode.
> We have to take a look at what "work" scale with the number of CPU on the
> lttng-consumerd side. One such thing is the live timer which is fired on an
> interval (default is 1s (1000000us)).
> You could test this hypothesis by streaming the trace instead of using the live
> lttng create --set-url ....
Yes, I agree with Jonathan's recommendation: you should compare this cpu usage with
that of the streaming mode of lttng by *not* using the "--live" option when creating
the trace session. It will at least help identify whether consumerd also exhibits this
cpu usage increase with number of cores in streaming mode, or if it is an expected
additional overhead of periodically flushing more cpu buffers (because there are more
cores) caused by the live timer.
More information about the lttng-dev