-
Notifications
You must be signed in to change notification settings - Fork 495
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
Allow to change the worker thread number in-flight #1855
Conversation
a6d8ee6
to
c30ce43
Compare
nice, long connect will not disconnect when change workers, I use redis-benchmark continuous write |
Thank you! I'm working on test cases. |
Should we prevent from setting the thread-cnt to a dangerous value( .e.g |
@mapleFU Yes, IntField will check the value range before setting.
|
{"workers", | ||
[](Server *srv, const std::string &k, const std::string &v) -> Status { | ||
if (!srv) return Status::OK(); | ||
srv->AdjustWorkerThreads(); | ||
return Status::OK(); | ||
}}, |
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.
Only those lines are newly added, rest is formatted by clang-format
@@ -417,8 +419,6 @@ void Server::SubscribeChannel(const std::string &channel, redis::Connection *con | |||
std::lock_guard<std::mutex> guard(pubsub_channels_mu_); | |||
|
|||
auto conn_ctx = ConnContext(conn->Owner(), conn->GetFD()); | |||
conn_ctxs_[conn_ctx] = true; |
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 where is using conn_ctxs_, so delete it.
aa99ecc
to
d99e14e
Compare
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.
A few comments, but the rest LGTM. @git-hulk Good job!
8297bc4
to
cb917e6
Compare
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.
LGTM.
I'm a bit confused about the ctor ordering here:
However, when |
The |
Got it, so finally resource is handled by dtor. |
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.
LGTM. Thanks
Thanks all, merging.. |
#1855 introduced the data race even only migrating the non-blocking connections. For example: T1: C0(connection) is running the command Config::Set on W0(worker) and C1 is running another command on W1. C0 got the exclusive lock for executing commands and C1 will wait for the lock inside ExecuteCommands. T2: C0 migrates C1 to W0 after reducing the number of worker threads, but the ExecuteCommands function will continue executing after migrating. So both W0 and W1 will access the C1 at the same time. To avoid this, I simply don't migrate the connection if it has any running command and delay to shutdown workers, so that old connections have a chance to finish the running command.
This closes #1802
Scaling up is as simple as starting new threads and adding them to the worker pool.
But scaling down is a bit complex since we need to migrate existing connections from
the to-be-removed workers to survived workers. This process is NOT so easy for the sake
of the blocking commands that will store its context(includes fd and owner pointer) in
different global variables and we need to find out and remove them. As far as I know,
it contains the below commands:
To make it simple, we would like to close those connections if the last command is
a blocking command. And we can improve this if any users complain about this.