[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?

[熊毓华]

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？

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20220309/049c6856/attachment.htm>