Commit | Line | Data |
---|---|---|
5e0cbfb0 PP |
1 | --- |
2 | id: channel-subbuf-size-vs-subbuf-count | |
3 | --- | |
4 | ||
5 | For each channel, an LTTng user may set its number of sub-buffers and | |
6 | their size. | |
7 | ||
8 | Note that there is a noticeable tracer's CPU overhead introduced when | |
9 | switching sub-buffers (marking a full one as consumable and switching | |
10 | to an empty one for the following events to be recorded). Knowing this, | |
11 | the following list presents a few practical situations along with how | |
12 | to configure sub-buffers for them: | |
13 | ||
14 | * **High event throughput**: in general, prefer bigger sub-buffers to | |
15 | lower the risk of losing events. Having bigger sub-buffers will | |
16 | also ensure a lower sub-buffer switching frequency. The number of | |
17 | sub-buffers is only meaningful if the channel is in overwrite mode: | |
18 | in this case, if a sub-buffer overwrite happens, you will still have | |
19 | the other sub-buffers left unaltered. | |
20 | * **Low event throughput**: in general, prefer smaller sub-buffers | |
21 | since the risk of losing events is already low. Since events | |
22 | happen less frequently, the sub-buffer switching frequency should | |
23 | remain low and thus the tracer's overhead should not be a problem. | |
24 | * **Low memory system**: if your target system has a low memory | |
25 | limit, prefer fewer first, then smaller sub-buffers. Even if the | |
26 | system is limited in memory, you want to keep the sub-buffers as | |
27 | big as possible to avoid a high sub-buffer switching frequency. | |
28 | ||
29 | You should know that LTTng uses CTF as its trace format, which means | |
30 | event data is very compact. For example, the average LTTng Linux kernel | |
31 | event weights about 32 bytes. A sub-buffer size of 1 MiB is | |
32 | thus considered big. | |
33 | ||
34 | The previous situations highlight the major trade-off between a few big | |
35 | sub-buffers and more, smaller sub-buffers: sub-buffer switching | |
36 | frequency vs. how much data is lost in overwrite mode. Assuming a | |
37 | constant event throughput and using the overwrite mode, the two | |
38 | following configurations have the same ring buffer total size: | |
39 | ||
40 | <script type="text/javascript"> | |
41 | document.write('<div class="img img-100" id="docsvg-channel-subbuf-size-vs-count-anim"></div>'); | |
42 | ||
43 | $(document).ready(function() { | |
44 | var doc = SVG('docsvg-channel-subbuf-size-vs-count-anim'); | |
45 | ||
46 | doc.viewbox(0, 0, 4.25, 2); | |
47 | ||
48 | var rb2 = rbBuildStdAnimated(doc, { | |
49 | div: 2, | |
50 | oR: 0.97, | |
51 | evDur: 300, | |
52 | evPerSubBuf: 16, | |
53 | consumerAfter: 25 | |
54 | }); | |
55 | var rb16 = rbBuildStdAnimated(doc, { | |
56 | div: 8, | |
57 | oR: 0.97, | |
58 | evDur: 300, | |
59 | evPerSubBuf: 4, | |
60 | consumerAfter: 6 | |
61 | }); | |
62 | ||
63 | rb2.getGroup().move(1, 1); | |
64 | rb16.getGroup().move(3.25, 1); | |
65 | }); | |
66 | </script> | |
67 | ||
68 | <noscript> | |
69 | <div class="err"> | |
70 | <p> | |
71 | <span class="t">Oops!</span>JavaScript must be enabled in | |
72 | order to view animations. | |
73 | </p> | |
74 | </div> | |
75 | </noscript> | |
76 | ||
77 | * **2 sub-buffers of 4 MiB each** lead to a very low sub-buffer | |
78 | switching frequency, but if a sub-buffer overwrite happens, half of | |
79 | the recorded events so far (4 MiB) are definitely lost. | |
80 | * **8 sub-buffers of 1 MiB each** lead to 4 times the tracer's | |
81 | overhead as the previous configuration, but if a sub-buffer | |
82 | overwrite happens, only the eighth of events recorded so far are | |
83 | definitely lost. | |
84 | ||
85 | In discard mode, the sub-buffers count parameter is pointless: use two | |
86 | sub-buffers and set their size according to the requirements of your | |
87 | situation. |