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

Don't do a DeepCopy in the remote state backend to avoid double copying #35114

Closed
wants to merge 1 commit into from

Conversation

alexott
Copy link
Contributor

@alexott alexott commented May 6, 2024

The updateStateHook performs DeepCopy to create a state object that is then pushed to the StateMgr.WriteState. If we use remote state backend, then it's doing DeepCopy again leading to increased pressure on the garbage collection in case of big states (couple of hundreds megabytes).

Fixes #35113

Target Release

1.8.x

Draft CHANGELOG entry

NEW FEATURES | UPGRADE NOTES | ENHANCEMENTS | BUG FIXES | EXPERIMENTS

  • Bug fix: improve performance of remote state backend on huge plans

The `updateStateHook` performs `DeepCopy` to create a `state` object that is then pushed
to the `StateMgr.WriteState`.  If we use remote state backend, then it's doing `DeepCopy`
again leading to increased pressure on the garbage collection in case of big
states (couple of hundreds megabytes).

Signed-off-by: Alex Ott <[email protected]>
// a reference to the given object and can potentially go on to mutate
// it after we return, but we want the snapshot at this point in time.
s.state = state.DeepCopy()
// We don't create a DeepCopy because it's already created in the `update_state_hook`
Copy link
Member

Choose a reason for hiding this comment

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

We can't assume that all calls to WriteState happen from a hook which has already copied the state. Unfortunately the interfaces that got us to this location don't guarantee their implementations are copying the state, and therefor also need to copy the state because of the global+mutable nature of the state storage.

Rather than changing a single statemgr.Writer implementation, I think we need to first ensure all callers have the same expectations. I think that will entail refining the stack of interfaces a little to ensure that we can assign responsibility of copying to a single layer.

@alexott
Copy link
Contributor Author

alexott commented May 7, 2024

@jbardin I thought about this, but it's a really big change - theoretically, we'll need to isolate the state under the interface, and implement copy-on-write for it and objects inside the state.

@alexott
Copy link
Contributor Author

alexott commented May 14, 2024

@jbardin would it help if we put this change under the feature flag?

@jbardin
Copy link
Member

jbardin commented May 14, 2024

@alexott,

Honestly I don't know right now. The simple change of removing the copy looks suspect, because that method can be called from many locations, not just the update hook. If we can prove there is no race or unexpected modification of cached state in all cases then it's something we can consider, but until then we can't be sure this doesn't have the possibility of damaging a user's state. In all likelihood if there is a solution to remove an extra copy we will adopt that.

@jbardin
Copy link
Member

jbardin commented May 15, 2024

Hi @alexott, I have an alternative proposal in #35164. This would effectively remove the extra copy for all implementations, while retaining the existing copy semantics of WriteState.

@jbardin
Copy link
Member

jbardin commented May 16, 2024

superseded by #35164

@jbardin jbardin closed this May 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Excessive DeepCopy usage in remote state backend leads to performance degradation
3 participants