Open kaomakino opened 5 years ago
Recruitment will stop after the first process class that can hold a role. So if you have 5 processes with stateless, 1 process with proxy, and you ask for 3 proxies, you'll get 1 proxy. This solves the problem for everything that's not storage, as storage is recruited differently.
The "everything but not storage" role you're looking for is called transaction
, as in, "anything in the transaction subsystem". Running one transaction
process and one storage
process will leave you with one storage server and one everything-else server.
That's super! Many thanks for the tip, Alex! So, this will solve the problem with storage. But what if I want to profile a TLog? I think we still want to have some flexibility here.
But what if I want to profile a TLog?
Then you run one process with class=log
.
class=transaction
is basically class=stateless+log
So... yeah, we have class=transaction
and class=log
, and they do different things. Admittedly horrible naming, but difficult to change now.
Ooooh, now I finally got it. Thanks!
If it helps, here is a visual guide I had earlier created from reading of the code, to help me plan class assignments:
But do keep in mind that GoodFit > UnsetFit > OkayFit
TIL. This is super useful! Thanks guys!
Yes, this is super useful! Thank you very much!! I'd suggest to cross post this in the forum too.
Today, fdbserver can be either 1. any role or 2. one specific role. When we want to run the entire cluster on a single machine (e.g. developer's laptop), it is very hard to create many processes of one specific role, because each process requires a good amount of memory. However, if we run the multiple roles in one process, it is extremely hard to properly profile for a certain role. We need a way to exclude a certain role here. For example:
This way, we can easily profile only the storage server. This is not only useful for profiling, but also debugging sometime.