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

keep allocations as small as possible #306

Merged
merged 3 commits into from
Jan 6, 2021

Conversation

wyndhblb
Copy link
Contributor

@wyndhblb wyndhblb commented Jan 6, 2021

Under some large streaming volume conditions (kafka consumption) this allocation can create tremendous GC pressure, where setting GOGC <= 10 still is not enough. Since this condition does not happen "very often" (but seems to happen more often in this streaming case then originally advertised by the original comment) we only allocate as much as we need not an extra 2Mb slab.

Conditions:

  • 2000 zstd encoded blocks second over 64 different streams byte blocks were in 1Mb chunks

Before this change:

  • with in several seconds Ram consumption would jump from 200Mb to over 30Gb
  • pprof indicated this allocation as the issue, however only ~500Mb inuse indicating GC had not cleaned up the other allocs
  • turning on GOGC=5, stemmed the speed of OOM, but still eventually OOMed

After this change:

  • ram usage is steady at around 200Mb and message rate seems same as before.

@wyndhblb
Copy link
Contributor Author

wyndhblb commented Jan 6, 2021

see --> IBM/sarama#1831

zstd/seqdec.go Outdated Show resolved Hide resolved
zstd/seqdec.go Show resolved Hide resolved
zstd/seqdec.go Outdated
s.out = s.out[:len(s.out)-maxBlockSize]
// over-allocating here can create a large amount of GC pressure so we try to keep
// it as contained as possible
addBytes := 1024 + (size - len(s.out))
Copy link
Owner

Choose a reason for hiding this comment

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

Suggested change
addBytes := 1024 + (size - len(s.out))
used := len(s.out) - startSize
addBytes := 256 + ll + ml + used>>2
// Clamp to max block size.
if used+addBytes > maxBlockSize {
addBytes = maxBlockSize - used
}

Copy link
Owner

Choose a reason for hiding this comment

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

Maybe something like this?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ok gave that change a whirl
there's about a 500-750Mb difference in the ram usage, higher using method, then the original size - len one, but it does seem to not get out of control, which is the desired effect.

Copy link
Owner

Choose a reason for hiding this comment

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

Great. I will merge when Ci tests are done and probably release it tomorrow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants