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

[Pubsub] reduce memory usage for channels that do not require total memory cap #23985

Merged
merged 2 commits into from
Apr 20, 2022

Conversation

mwtian
Copy link
Member

@mwtian mwtian commented Apr 18, 2022

Why are these changes needed?

In a1e06f6, memory bound was added for each subscribed entity in the publisher. It adds two extra std::deque per subscribed entity, which turns out to cost a lot more memory when there are a large number of ObjectRefs: #23853 (comment)

This PR avoids the extra memory usage for entities in channels unlikely to grow too large, i.e. all channels except those for logs and error info. Subscribed entity memory usage no longer shows up in the memory profile when there are 1M object refs:
image
Raw data: profile006.pb.gz

Related issue number

#23604

Checks

  • I've run scripts/format.sh to lint the changes in this PR.
  • I've included any doc changes needed for https://docs.ray.io/en/master/.
  • I've made sure the tests are passing. Note that there might be a few flaky tests, see the recent failures at https://flakey-tests.ray.io/
  • Testing Strategy
    • Unit tests
    • Release tests
    • This PR is not tested :(

@mwtian mwtian marked this pull request as ready for review April 18, 2022 22:43
@mwtian mwtian added the tests-ok The tagger certifies test failures are unrelated and assumes personal liability. label Apr 18, 2022

/// State for an entity that streams published messages to subscribers, with total size
/// cap.
class StreamEntityState : public EntityState {
Copy link
Contributor

Choose a reason for hiding this comment

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

I think "Stream" is not really the right word here since they both send streams to the subscribers. Maybe something like "CappedEntityState" vs "BufferedEntityState"?

Also, could you update the comment to explain what happens when we exceed the cap and to explain when Basic vs Streamed should be used/why we have two different kinds?

Copy link
Member Author

Choose a reason for hiding this comment

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

Good point. Renamed to CappedEntityState and added comment on their differences.

Copy link
Contributor

@stephanie-wang stephanie-wang left a comment

Choose a reason for hiding this comment

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

Nice find! It looks good, I just left some comments about naming and documentation.

@@ -90,24 +101,32 @@ const absl::flat_hash_map<SubscriberID, SubscriberState *> &EntityState::Subscri
return subscribers_;
}

SubscriptionIndex::SubscriptionIndex(rpc::ChannelType channel_type)
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: I feel it's a little bit wired to put channel_type into SubscriptionIndex. it seems that it's only used to construct EntityState. We don't need to store it inside channel_type_.

Copy link
Contributor

Choose a reason for hiding this comment

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

Another thing I feel bad about is that it's an application layer decision, but here it's hardcoded in the infra layer. I'm wondering whether we can make it better?

Copy link
Contributor

Choose a reason for hiding this comment

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

synced offline. I'm good with this right now since it's still maintainable.

@fishbone fishbone merged commit 34fb092 into ray-project:master Apr 20, 2022
@mwtian mwtian deleted the pubsub-state branch April 20, 2022 01:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
tests-ok The tagger certifies test failures are unrelated and assumes personal liability.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants