openshift-ci-robot
commented
3 months ago @jotak: This pull request references NETOBSERV-1564 which is a valid jira issue.
Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the spike to target the "4.17.0" version, but no target version was set.
In response to [this](https://github.com/netobserv/netobserv-ebpf-agent/pull/348):
>## Description
>
>Flushing (without throttling) has a nefast effect in high stressed scenario, generating a lot of evictions from maps, resulting in many more flows generated.
>
>High stressed scenarios should rather rely on rb+accounter, which better handles the number of generated flows.
>
>Also, use errno as the reason for the metric
>
>With this change + high stress scenario I'm seeing better CPU but more memory slightly increased:
>
>
>
>overall, -50% CPU and +10% memory
>
>This should be tested against cluster-density-v2
>
>
>
>## Dependencies
>
>
>n/a
>
>## Checklist
>
>If you are not familiar with our processes or don't know what to answer in the list below, let us know in a comment: the maintainers will take care of that.
>
>* [ ] Will this change affect NetObserv / Network Observability operator? If not, you can ignore the rest of this checklist.
>* [ ] Is this PR backed with a JIRA ticket? If so, make sure it is written as a title prefix _(in general, PRs affecting the NetObserv/Network Observability product should be backed with a JIRA ticket - especially if they bring user facing changes)._
>* [ ] Does this PR require product documentation?
> * [ ] If so, make sure the JIRA epic is labelled with "documentation" and provides a description relevant for doc writers, such as use cases or scenarios. Any required step to activate or configure the feature should be documented there, such as new CRD knobs.
>* [ ] Does this PR require a product release notes entry?
> * [ ] If so, fill in "Release Note Text" in the JIRA.
>* [ ] Is there anything else the QE team should know before testing? E.g: configuration changes, environment setup, etc.
> * [ ] If so, make sure it is described in the JIRA ticket.
>* QE requirements (check 1 from the list):
> * [ ] Standard QE validation, with pre-merge tests unless stated otherwise.
> * [ ] Regression tests only (e.g. refactoring with no user-facing change).
> * [ ] No QE (e.g. trivial change with high reviewer's confidence, or per agreement with the QE team).
>
Instructions for interacting with me using PR comments are available [here](https://prow.ci.openshift.org/command-help?repo=netobserv%2Fnetobserv-ebpf-agent). If you have questions or suggestions related to my behavior, please file an issue against the [openshift-eng/jira-lifecycle-plugin](https://github.com/openshift-eng/jira-lifecycle-plugin/issues/new) repository.
github-actions[bot]
codecov[bot]
Amoghrd
msherif1234
jotak
openshift-ci[bot]
Description
Flushing (without throttling) has a harmful effect in high stressed scenario, generating a lot of evictions from maps, resulting in many more flows generated.
High stressed scenarios should rather rely on rb+accounter, which better handles the number of generated flows, than trying to force using maps this way
Also, use errno as the reason for the metric
With this change + high stress scenario I'm seeing better CPU but more memory slightly increased:
overall, -50% CPU and +10% memory
This should be tested against cluster-density-v2
Dependencies
n/a
Checklist
If you are not familiar with our processes or don't know what to answer in the list below, let us know in a comment: the maintainers will take care of that.