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-jul...@efficios.com> > 发送时间:2022-03-09 00:39:01 (星期三) > 收件人: "熊毓华" <xiongyu...@zju.edu.cn> > 抄送: lttng-dev <lttng-dev@lists.lttng.org>, "Mathieu Desnoyers" > <mathieu.desnoy...@efficios.com>, yc...@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 _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
