Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reduce memory allocations during endpoint restore #12405

Merged
merged 2 commits into from Jul 6, 2020

Conversation

tklauser
Copy link
Member

@tklauser tklauser commented Jul 3, 2020

First commit is preparatory and moves a function from pkg/common
into pkg/endpoint which is only used there.

Second commit avoids excessive allocations during endpoint restore:

The way endpoint state currently is restored from header files could
potentially lead to a lot of memory allocations, partially due to the fact
that the respective base64 encoded state is converted to a string after
being read and then converted back to a byte slice in order to decode
it. Since every conversion of a byte slice to a string allocates (due to
the fact that strings are immutable in Go), this essentially doubles the
memory that is used which could lead to memory allocation spikes during
restore.

Avoid this by reading the base64 encoded endpoint state into a
byte slice directly and thus reducing the size and number of
allocations.

Before:

EndpointSuite.BenchmarkReadEPsFromDirNames        5000            399980 ns/op           83665 B/op        743 allocs/op

After:

EndpointSuite.BenchmarkReadEPsFromDirNames        5000            369643 ns/op           73479 B/op        731 allocs/op

For #12367 to slightly reduce chances of OOM.

Reduce memory allocations during endpoint restore

The GetCiliumVersionString function is only used in a single function
within this package. Move it where it is used to reduce the package size
of pkg/common which is imported all over the place.

Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
The way endpoint state currently is restored from header files could
potentially lead to a lot of memory allocations, partially due to the fact
that the respective base64 encoded state is converted to a string after
being read and then converted back to a byte slice in order to decode
it. Since every conversion of a byte slice to a string allocates (due to
the fact that strings are immutable in Go), this essentially doubles the
memory that is used which could lead to memory allocation spikes during
restore.

Avoid this by reading the base64 encoded endpoint state into a
byte slice directly and thus reducing the size and number of
allocations.

Before:

  EndpointSuite.BenchmarkReadEPsFromDirNames	    5000	    399980 ns/op	   83665 B/op	     743 allocs/op

After:

  EndpointSuite.BenchmarkReadEPsFromDirNames	    5000	    369643 ns/op	   73479 B/op	     731 allocs/op

Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
@tklauser tklauser added kind/performance There is a performance impact of this. release-note/misc This PR makes changes that have no direct user impact. labels Jul 3, 2020
@tklauser tklauser requested review from a team as code owners July 3, 2020 13:27
@tklauser
Copy link
Member Author

tklauser commented Jul 3, 2020

test-me-please

@coveralls
Copy link

Coverage Status

Coverage increased (+0.02%) to 36.936% when pulling 23e7952 on pr/tklauser/ep-restore-reduce-alloc into 86729fb on master.

Copy link
Member

@christarazi christarazi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice!

Copy link
Member

@pchaigno pchaigno left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice catch!

@maintainer-s-little-helper maintainer-s-little-helper bot added the ready-to-merge This PR has passed all tests and received consensus from code owners to merge. label Jul 6, 2020
@pchaigno pchaigno merged commit bd16892 into master Jul 6, 2020
@pchaigno pchaigno deleted the pr/tklauser/ep-restore-reduce-alloc branch July 6, 2020 07:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/performance There is a performance impact of this. ready-to-merge This PR has passed all tests and received consensus from code owners to merge. release-note/misc This PR makes changes that have no direct user impact.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants