Re: "lttng enable-channel --tracefile-size" bug

Re: "lttng enable-channel --tracefile-size" bug

[Julien Desfossez]

> Hi,
> it looks like for the "enable-channel" command, "tracefile-size" option
> doesn't take effect, bellow are all the options, the resulted files have
> the actual size the same as the size specified by subbuf-size option:
>  
> # lttng -V
> lttng (LTTng Trace Control) 2.7.1 - Herbe à Détourne
> 
> $ lttng enable-channel chan_name -u -s session_name --discard
> --num-subbuf 8 
>             --subbuf-size 32M --tracefile-size 8K --tracefile-count 8
> --buffers-pid

Yes, that is the expected behaviour, we work with packets (sub-buffers),
so the smallest unit we can store is the subbuf-size.

With 2.7.3 I get this warning when I try your command:
Warning: Tracefile size rounded up from (8192) to subbuffer size (33554432)

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

Re: "lttng enable-channel --tracefile-size" bug

[John Smith]

[-- Attachment #1.1: Type: text/plain, Size: 1274 bytes --]

Julien,
thanks, I was mislead by the 2.7 documentation saying:
"...parameters of enable-channel are --tracefile-sizeand --tracefile-count,
which respectively limit the size of each trace file and the their count
for a given channel. "
In this case the tracefile-size option should be removed, will it become
useful in the future releases or has a more subtle use?

thanks, John

On Sat, May 28, 2016 at 6:21 AM, Julien Desfossez <jdesfossez@efficios.com>
wrote:

> > Hi,
> > it looks like for the "enable-channel" command, "tracefile-size" option
> > doesn't take effect, bellow are all the options, the resulted files have
> > the actual size the same as the size specified by subbuf-size option:
> >
> > # lttng -V
> > lttng (LTTng Trace Control) 2.7.1 - Herbe à Détourne
> >
> > $ lttng enable-channel chan_name -u -s session_name --discard
> > --num-subbuf 8
> >             --subbuf-size 32M --tracefile-size 8K --tracefile-count 8
> > --buffers-pid
>
> Yes, that is the expected behaviour, we work with packets (sub-buffers),
> so the smallest unit we can store is the subbuf-size.
>
> With 2.7.3 I get this warning when I try your command:
> Warning: Tracefile size rounded up from (8192) to subbuffer size (33554432)
>
> Julien
>

[-- Attachment #1.2: Type: text/html, Size: 5463 bytes --]

[-- Attachment #2: Type: text/plain, Size: 156 bytes --]

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

Re: "lttng enable-channel --tracefile-size" bug

[Julien Desfossez]

> Julien,
> thanks, I was mislead by the 2.7 documentation saying:
> "...parameters
> of |enable-channel| are |--tracefile-size|and |--tracefile-count|, which
> respectively limit the size of each trace file and the their count for a
> given channel. "
> In this case the tracefile-size option should be removed, will it become
> useful in the future releases or has a more subtle use? 

No, the tracefile-size options does what it says, the limitation is that
the smallest unit it can work with is the subbuf-size. So the smallest
tracefile size you can have is the subbuf-size.

If you are using 4k subbuffers and you limit the size of the tracefiles
to 4M, then you will have at most 1000 full packets in each tracefile.
But if you have subbuffers of 8M, the smallest tracefile size you can
have is 8M.

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

Re: "lttng enable-channel --tracefile-size" bug

[John Smith]

[-- Attachment #1.1: Type: text/plain, Size: 1261 bytes --]

thanks, just one more question, I would think that it would be more
efficient to have multiple sub-buffers writing to a file versus one
sub-buffer to one file,. Of course, when the file gets overwritten
(rolled-over by the tracefile-count option)  multiple sub-buffers are lost.
Do you have any use case recommendation?
John

On Sun, May 29, 2016 at 12:48 PM, Julien Desfossez <jdesfossez@efficios.com>
wrote:

> > Julien,
> > thanks, I was mislead by the 2.7 documentation saying:
> > "...parameters
> > of |enable-channel| are |--tracefile-size|and |--tracefile-count|, which
> > respectively limit the size of each trace file and the their count for a
> > given channel. "
> > In this case the tracefile-size option should be removed, will it become
> > useful in the future releases or has a more subtle use?
>
> No, the tracefile-size options does what it says, the limitation is that
> the smallest unit it can work with is the subbuf-size. So the smallest
> tracefile size you can have is the subbuf-size.
>
> If you are using 4k subbuffers and you limit the size of the tracefiles
> to 4M, then you will have at most 1000 full packets in each tracefile.
> But if you have subbuffers of 8M, the smallest tracefile size you can
> have is 8M.
>
> Julien
>

[-- Attachment #1.2: Type: text/html, Size: 1812 bytes --]

[-- Attachment #2: Type: text/plain, Size: 156 bytes --]

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

Re: "lttng enable-channel --tracefile-size" bug

[Julien Desfossez]

> thanks, just one more question, I would think that it would be more
> efficient to have multiple sub-buffers writing to a file versus one
> sub-buffer to one file,. Of course, when the file gets overwritten
> (rolled-over by the tracefile-count option)  multiple sub-buffers are
> lost.  Do you have any use case recommendation?  John

It all depends on your use-case, usually the tracefile-count option is
used to keep an relatively short time-frame history on disk, so the size
you keep on disk is dependant on how long you want this history to be
and the rate at which events are recorded.

The sub-buffer size is not directly related to this option, when a
tracefile is overwritten all its content is truncated regardless the
number of sub-buffers. So having 10 sub-buffers of 4k or 1 sub-buffer of
40k is basically the same thing for the tracefile rotation.

In terms of performance, handling the rotation adds some work for the
consumerd after extracting the data, so if it is too frequent, you might
see more discarded events. On the other hand, if your tracefiles are
really big, when you overwrite one, you loose a lot of old data (more or
less old depending on the tracefile-count option). So it really is a
tradeoff you have to think about with your use-case.

I hope it clarifies the situation.

Thanks,

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

"lttng enable-channel --tracefile-size" bug

[John Smith]

[-- Attachment #1.1: Type: text/plain, Size: 476 bytes --]

Hi,
it looks like for the "enable-channel" command, "tracefile-size" option
doesn't take effect, bellow are all the options, the resulted files have
the actual size the same as the size specified by subbuf-size option:

# lttng -V
lttng (LTTng Trace Control) 2.7.1 - Herbe à Détourne

$ lttng enable-channel chan_name -u -s session_name --discard --num-subbuf
8
            --subbuf-size 32M --tracefile-size 8K --tracefile-count 8
--buffers-pid

thanks, John

[-- Attachment #1.2: Type: text/html, Size: 627 bytes --]

[-- Attachment #2: Type: text/plain, Size: 156 bytes --]

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