Uploaded image for project: 'Network Observability'
  1. Network Observability
  2. NETOBSERV-1564

[Agent perfs] The accounter shouldn't generate many more flows

XMLWordPrintable

    • Icon: Story Story
    • Resolution: Done
    • Icon: Normal Normal
    • netobserv-1.7
    • netobserv-1.6, netobserv-1.6-candidate
    • None
    • 3
    • False
    • None
    • False
    • Hide
      Previously under high stress, the eBPF agents were susceptible to enter in a state where they would generate a high number of small flows, almost not aggregated. With this patch, the aggregation process is still maintained under high stress, resulting in less flows being created, which improves the resource consumption not only in the eBPF agent but also in flowlogs-pipeline and Loki.
      Show
      Previously under high stress, the eBPF agents were susceptible to enter in a state where they would generate a high number of small flows, almost not aggregated. With this patch, the aggregation process is still maintained under high stress, resulting in less flows being created, which improves the resource consumption not only in the eBPF agent but also in flowlogs-pipeline and Loki.
    • 3
    • NetObserv - Sprint 253, NetObserv - Sprint 254, NetObserv - Sprint 255

      While writing this blog https://github.com/netobserv/documents/pull/68 there's something I don't explain and leads me to think perhaps there is a bug in the accounter. In the last chapter of this blog before the conclusion I describe a "flows runaway" where suddenly the ring buffer becomes more used and leads to a much increased number of flows generated (something like x4) despite monitored traffic staying flat.

      The fact that the ring buffer came into play was done on purpose, by decreasing the hashmap sizes.

      However, I feel like the accounter doesn't hold up: it is supposed to aggregate flows in the user space (roughly the same as what the maps do in kernel space), hence despite using more CPU, it shouldn't generate more flows?  I would expect roughly the same number of flows to be generated from maps or from accounter. Or what is wrong in this reasoning?

            jtakvori Joel Takvorian
            jtakvori Joel Takvorian
            Amogh Rameshappa Devapura Amogh Rameshappa Devapura
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: