fausturs commented on issue #2756:
URL: https://github.com/apache/brpc/issues/2756#issuecomment-2330969022
我提供一个个人的角度，可以讨论一下。
因为新的keytable的策略，是return到一个pthread 的thread
local的list中。但没办法保证的是，同一个keytable被borrow后，会被return到同一个pthread里。
本来其实也没什么问题，只要等待足够时间，每个pthread中，就会create足够的keytable。但是可能，目前的一些task的调度策略，会使得pthread中的keytable数量像波浪一样震荡，使得keytable稳定的总数大大增加。
可以看这么一个例子
```c++
void* print_log(void *) {
std::random_device rd;
std::mt19937 mt{rd()};
std::uniform_int_distribution<uint64_t> uid(0, 100000);
bthread_usleep(50000 + uid(mt));
LOG(INFO) << "some log here xxx";
return NULL;
}
class GreeterImpl final : public Greeter {
void SayHello(google::protobuf::RpcController* controller, const
HelloRequest* request, HelloReply* response, google::protobuf::Closure* done)
override {
brpc::ClosureGuard done_guard(done);
brpc::Controller* cntl = static_cast<brpc::Controller*>(controller);
(void)print_log(NULL);
std::string message = "Hello " + request->name() + "!\n";
response->set_message(message);
}
};
```
先做sleep，再进行LOG（相当于使用keytable），可以看到keytable的数量非常稳定。因为这里，每个pthread里，有一个keytable就可以了。
但我们换一下位置
```c++
void* print_log(void *) {
std::random_device rd;
std::mt19937 mt{rd()};
std::uniform_int_distribution<uint64_t> uid(0, 100000);
LOG(INFO) << "some log here xxx";
bthread_usleep(50000 + uid(mt));
return NULL;
}
class GreeterImpl final : public Greeter {
void SayHello(google::protobuf::RpcController* controller, const
HelloRequest* request, HelloReply* response, google::protobuf::Closure* done)
override {
brpc::ClosureGuard done_guard(done);
brpc::Controller* cntl = static_cast<brpc::Controller*>(controller);
(void)print_log(NULL);
std::string message = "Hello " + request->name() + "!\n";
response->set_message(message);
}
};
```
可以看到keytable有一个持续的增长。
这里从统计意义上来说，增长可能会一直存在，因为当前worker的task
sleep了（或者是等待某个锁），之后它好像会尝试从其他队列steal一个pendding的任务。随着这些任务都sleep（或者都block在某个锁上），这个work所在的pthread的存量keyTable会被持续消耗。而且这些keytable大概率不会被return到这个pthread了。
所以，pthread中的keytables，不是维持在一个较为稳定的状态，而是有着潮水一样的涨落。随着borrow的失败，只能不停的new新的keytable
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@brpc.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@brpc.apache.org
For additional commands, e-mail: dev-h...@brpc.apache.org
