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

Pipeline: use notify instead of polling for ExchangeReceiver #9073

Merged
merged 40 commits into from
Sep 27, 2024

Conversation

SeaRise
Copy link
Contributor

@SeaRise SeaRise commented May 22, 2024

What problem does this PR solve?

Issue Number: ref #8869

Problem Summary:

What is changed and how it works?

The cpu usage of wait reactor is reduced to 0 in tpch50.
c72a55fd-0cd5-4fe2-87e2-beb5e5631d0e

Check List

Tests

Tested tpch50, no performance regression

  • Unit test
  • Integration test
  • Manual test (add detailed scripts or steps below)
  • No code

Side effects

  • Performance regression: Consumes more CPU
  • Performance regression: Consumes more Memory
  • Breaking backward compatibility

Documentation

  • Affects user behaviors
  • Contains syntax changes
  • Contains variable changes
  • Contains experimental features
  • Changes MySQL compatibility

Release note

None

@ti-chi-bot ti-chi-bot bot added release-note-none Denotes a PR that doesn't merit a release note. size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. labels May 22, 2024
@SeaRise SeaRise changed the title Pipeline: use notify instead of polling for ExchangeReceiver DNM: Pipeline: use notify instead of polling for ExchangeReceiver May 22, 2024
@@ -374,6 +374,8 @@ class DAGContext
/* const */ bool is_disaggregated_task = false; // a disagg task handling by the write node
// `tunnel_set` is always set by `MPPTask` and is used later.
MPPTunnelSetPtr tunnel_set;
// `mpp_receiver_set` is always set by `MPPTask` and is used later.
Copy link
Contributor

Choose a reason for hiding this comment

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

why move it to here

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

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

It can be solved by adding a public function?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

A public function can be added here, but since mpp-tunnel-set is already in the public section, it might be better to maintain consistency.

Copy link
Contributor

Choose a reason for hiding this comment

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

But it will change the destructor order in DAGContext, I'm not sure if there is some potential risk of 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, updated.

@@ -152,6 +150,15 @@ MPMCQueueResult ReceivedMessageQueue::pop(size_t stream_id, ReceivedMessagePtr &
grpc_recv_queue.tryDequeue();
#endif
}
ExchangeReceiverMetric::subDataSizeMetric(*data_size_in_queue, recv_msg->getPacket().ByteSizeLong());
Copy link
Contributor

Choose a reason for hiding this comment

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

Should be a bug in the previous implementation, this subDataSizeMetric should only be called if recv_msg->getRemainingConsumers()->fetch_sub(1) == 1

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, updated.


extern thread_local NotifyFuturePtr current_notify_future;
extern thread_local NotifyFuture * current_notify_future;
Copy link
Contributor

Choose a reason for hiding this comment

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

Looks like this change may increase the risk of using a object that have been already released, is it by design that the current_notify_future will not be released during its lifecycle?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yes, current_notify_future is only released when the pipeline task changes from wait-for-notify to running

: queue(log_, std::forward<Args>(args)...)
{}

void registerTask(TaskPtr && task) override { queue.registerPipeReadTask(std::move(task)); }
Copy link
Contributor

Choose a reason for hiding this comment

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

maybe rename it to registerPipelineReadTask?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Because this is an override of NotifyFuture::registerTask, it cannot be renamed

Copy link
Contributor

@windtalker windtalker left a comment

Choose a reason for hiding this comment

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

lgtm

@ti-chi-bot ti-chi-bot bot added approved needs-1-more-lgtm Indicates a PR needs 1 more LGTM. labels Sep 23, 2024
private:
using QueueImpl = LooseBoundedMPMCQueue<ReceivedMessagePtr>;
// these are unbounded queues.
std::unique_ptr<QueueImpl> queue = std::make_unique<QueueImpl>(std::numeric_limits<size_t>::max());
Copy link
Contributor

Choose a reason for hiding this comment

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

Why use unique_ptr? Also, how about letting MSGChannel inherits LooseBoundedMPMCQueue<ReceivedMessagePtr>?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ref #7963,
Because LooseBoundedMPMCQueue includes locks, it must use unique_ptr or shared_ptr somewhere.

void registerPipeWriteTask(TaskPtr && task) { queue.registerPipeWriteTask(std::move(task)); }

private:
GRPCRecvQueue<ReceivedMessagePtr> queue;
Copy link
Contributor

Choose a reason for hiding this comment

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

How about directly letting GRPCRecvNotifyQueue inherit GRPCRecvQueue<ReceivedMessagePtr>? If so, these functions do not need to be written, only the registerTask function is required.

Signed-off-by: gengliqi <gengliqiii@gmail.com>
@ti-chi-bot ti-chi-bot bot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. and removed size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. labels Sep 27, 2024
Signed-off-by: gengliqi <gengliqiii@gmail.com>
Signed-off-by: gengliqi <gengliqiii@gmail.com>
Copy link
Contributor

@gengliqi gengliqi left a comment

Choose a reason for hiding this comment

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

LGTM

Copy link
Contributor

ti-chi-bot bot commented Sep 27, 2024

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: gengliqi, windtalker

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:
  • OWNERS [gengliqi,windtalker]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@ti-chi-bot ti-chi-bot bot added lgtm and removed needs-1-more-lgtm Indicates a PR needs 1 more LGTM. labels Sep 27, 2024
Copy link
Contributor

ti-chi-bot bot commented Sep 27, 2024

[LGTM Timeline notifier]

Timeline:

  • 2024-09-23 03:00:55.990452415 +0000 UTC m=+1448525.730876363: ☑️ agreed by windtalker.
  • 2024-09-27 10:48:38.150357477 +0000 UTC m=+6273.570570488: ☑️ agreed by gengliqi.

@SeaRise
Copy link
Contributor Author

SeaRise commented Sep 27, 2024

/retest

Signed-off-by: gengliqi <gengliqiii@gmail.com>
@gengliqi
Copy link
Contributor

/retest

@ti-chi-bot ti-chi-bot bot merged commit 92e8dac into pingcap:master Sep 27, 2024
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved lgtm release-note-none Denotes a PR that doesn't merit a release note. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants