-
Story
-
Resolution: Done
-
Normal
-
netobserv-1.6, netobserv-1.6-candidate
-
None
-
3
-
False
-
None
-
False
-
-
-
-
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?
- links to
-
RHSA-2024:135231 Network Observability 1.7.0 for OpenShift
- mentioned on