| 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: 17, |
| 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. |