-
Notifications
You must be signed in to change notification settings - Fork 6.9k
[core] Add comments explaining the usage of the ray_syncer_ channels in the Raylet
#58342
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -224,7 +224,6 @@ NodeManager::NodeManager( | |
| cluster_lease_manager_(cluster_lease_manager), | ||
| record_metrics_period_ms_(config.record_metrics_period_ms), | ||
| placement_group_resource_manager_(placement_group_resource_manager), | ||
| next_resource_seq_no_(0), | ||
|
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. this was vestigial
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. what does vestigial mean lol |
||
| ray_syncer_(io_service_, self_node_id_.Binary()), | ||
| worker_killing_policy_(std::make_shared<GroupByOwnerIdWorkerKillingPolicy>()), | ||
| memory_monitor_(std::make_unique<MemoryMonitor>( | ||
|
|
@@ -322,16 +321,29 @@ void NodeManager::RegisterGcs() { | |
| auto on_node_change_subscribe_done = [this](Status status) { | ||
| RAY_CHECK_OK(status); | ||
|
|
||
| // Register resource manager and scheduler | ||
| // RESOURCE_VIEW is used to synchronize available resources across Raylets. | ||
| // | ||
| // LocalResourceManager::CreateSyncMessage will be called periodically to collect | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think it's good to mention that it's both periodically called and also on-demand when local resources change.
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Actually, it is not called on-demand! Inside of
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oh whattt, thanks for the clarification 🤯 |
||
| // the local Raylet's usage to broadcast to others (via the GCS). The updates are | ||
| // versioned inside of `LocalResourceManager` to avoid unnecessary broadcasts. | ||
| // | ||
| // NodeManager::ConsumeSyncMessage will be called when a sync message containing | ||
| // other Raylets' resource usage is received. | ||
| ray_syncer_.Register( | ||
| /* message_type */ syncer::MessageType::RESOURCE_VIEW, | ||
| /* reporter */ &cluster_resource_scheduler_.GetLocalResourceManager(), | ||
| /* receiver */ this, | ||
| /* pull_from_reporter_interval_ms */ | ||
| report_resources_period_ms_); | ||
|
|
||
| // Register a commands channel. | ||
| // It's only used for GC right now. | ||
| // COMMANDS is used only to broadcast a global request to call the Python garbage | ||
| // collector on all Raylets when the cluster is under memory pressure. | ||
| // | ||
| // Periodic collection is disabled, so this command is only broadcasted via | ||
| // `OnDemandBroadcasting` (which will call NodeManager::CreateSyncMessage). | ||
| // | ||
| // NodeManager::ConsumeSyncMessage is called to execute the GC command from other | ||
| // Raylets. | ||
| ray_syncer_.Register( | ||
| /* message_type */ syncer::MessageType::COMMANDS, | ||
| /* reporter */ this, | ||
|
|
@@ -346,6 +358,9 @@ void NodeManager::RegisterGcs() { | |
| // If plasma store is under high pressure, we should try to schedule a global | ||
| // gc. | ||
| if (triggered_by_global_gc) { | ||
| // Always increment the sync message version number so that all GC commands | ||
| // are sent indiscriminately. | ||
| gc_command_sync_version_++; | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think it's good to mention that even though we call OnDemandBroadcasting, it's only sent to the GCS and not to other raylets
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think it would also be good to mention in BroadcastMessage or the map of sync_reactors_ that for node managers, we only have one bidi reactor which is to the GCS. GCS has multiple bidi reactors, one for each node. Hence just to emphasize that it's NOT all to all on the raylet level, it's node to GCS to all nodes
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I included this where we initialize the syncer and in the ray_syncer_ field comment. Putting it here specifically felt odd because it applies to all usage of the syncer. |
||
| ray_syncer_.OnDemandBroadcasting(syncer::MessageType::COMMANDS); | ||
| } | ||
| }, | ||
|
|
@@ -3032,19 +3047,25 @@ void NodeManager::ConsumeSyncMessage( | |
|
|
||
| std::optional<syncer::RaySyncMessage> NodeManager::CreateSyncMessage( | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. nit: Can we rename this to CreateSyncCommandsMessage?
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. we cannot because it's a virtual method to implement the sync broadcaster interface. I tried to do that already :'(
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ohh... I see both LocalResourceManager and NodeManager inherit from the syncer class and override this RIP |
||
| int64_t after_version, syncer::MessageType message_type) const { | ||
| // This method is only called for the COMMANDS channel, as the RESOURCE_VIEW | ||
| // channel goes through the LocalResourceManager. | ||
| RAY_CHECK_EQ(message_type, syncer::MessageType::COMMANDS); | ||
|
|
||
| // Serialize the COMMANDS message to a byte string to be nested inside the sync message. | ||
edoakes marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| std::string serialized_commands_sync_msg; | ||
| syncer::CommandsSyncMessage commands_sync_message; | ||
| commands_sync_message.set_should_global_gc(true); | ||
| commands_sync_message.set_cluster_full_of_actors_detected(resource_deadlock_warned_ >= | ||
| 1); | ||
| RAY_CHECK(commands_sync_message.SerializeToString(&serialized_commands_sync_msg)); | ||
|
|
||
| // Populate the sync message. | ||
edoakes marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| syncer::RaySyncMessage msg; | ||
| msg.set_version(absl::GetCurrentTimeNanos()); | ||
| msg.set_version(gc_command_sync_version_); | ||
| msg.set_node_id(self_node_id_.Binary()); | ||
| msg.set_message_type(syncer::MessageType::COMMANDS); | ||
| std::string serialized_msg; | ||
| RAY_CHECK(commands_sync_message.SerializeToString(&serialized_msg)); | ||
| msg.set_sync_message(std::move(serialized_msg)); | ||
| msg.set_sync_message(std::move(serialized_commands_sync_msg)); | ||
|
|
||
| return std::make_optional(std::move(msg)); | ||
| } | ||
|
|
||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no behavior change, just reversed the early return logic