[lttng-dev] In lttng-live mode, if the printing speed cannot keep up with the generation speed of the parsed ctf data, where will the data be stored?

[Jonathan Rajotte-Julien]

On Wed, Mar 09, 2022 at 01:26:42AM +0800, 熊毓华 wrote:
> If for some reason (for example, here my socket send function in print_message
> is blocked and the Babeltrace2 may be suspended), the speed of the reader
> (babeltrace2) cannot keep up with the speed of the
> producer(lttng/lttng-consumerd), can the size of this buffer("lttng-relayd" )
> be set? How much data can it store？

Unless you are using --tracefile-size and --tracefile-count (man lttng-enable-channel), the limit here is
the backing filesystem of the host running lttng-relayd.

I suggest that you have a look at the overall architecture of lttng before going
further [1].

[1] https://lttng.org/docs/v2.13/#doc-plumbing

Cheers

> 
> Looking forward to your reply！
> 
> thx
> 
> Yuhua
> 
> 
> 
> 
> -----原始邮件-----
> 发件人:"Jonathan Rajotte-Julien" <jonathan.rajotte-julien at efficios.com>
> 发送时间:2022-03-09 00:39:01 (星期三)
> 收件人: "熊毓华" <xiongyuhua at zju.edu.cn>
> 抄送: lttng-dev <lttng-dev at lists.lttng.org>, "Mathieu Desnoyers" <mathieu.desnoyers at efficios.com>, ychen at northwestern.edu
> 主题: Re: In lttng-live mode, if the printing speed cannot keep up with the generation speed of the parsed ctf data, where will the data be stored?
> 
> 
> Hi
> 
> 
> I wonder if my socket recv function is blocked on the other end, causing the socket send function to block in print_message function in babeltrace2;or when printing to the console, the printing speed can't keep up with the parsed CTF data generation speed and the print buffer is also full.
> 
> In this case, how will Babeltrace2 handle the parsed CTF data that has not been sent yet, store them in a buffer, a queue or just discard them? Or would the blocking directly cause LTTng to discard the original CTF data at the ring buffer before LTTng Consumer daemon?
> 
> 
> 
> Not sure I understand your setup but when using lttng-live, you are effectively reading from the data that lttng-relayd is collecting, piece by piece.
> The producing side is not affected by the speed at which the reader (babeltrace2) consume data from lttng-relayd using the lttng-live protocol.
> There might be some corner case here and there but for most base usage of the "live" feature reader (babeltrace2) and producer(lttng/lttng-consumerd)
> are "decoupled". You can consider the "lttng-relayd" (and the trace on the filesystem) as the "buffer" here.

-- 
Jonathan Rajotte-Julien
EfficiOS