contents/understanding-lttng/core-concepts/channel/channel-subbuf-size-vs-subbuf-count.md

   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&nbsp;bytes. A sub-buffer size of 1&nbsp;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&nbsp;MiB) are definitely lost.
  80   * **8 sub-buffers of 1 MiB each** lead to 4&nbsp;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.