-
Notifications
You must be signed in to change notification settings - Fork 22
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
Bound tokio worker thread count #686
Comments
By default, the multi-thread tokio runtime will spawn a number of worker threads equal to the number of CPUs observed on the system. On a gimlet, that means north of 256 threads (128 CPUs * 2 runtimes), which is woefully excessive. The one runtime is used to run dropshot (and its associated bits), and can probably be limited to 4 workers. Determining the worker count for the propolis-specific runtime will require a bit more care, as it probably does need to be scaled with the performance expectations of the instance (more disks will drive more IOPS will require more workers). |
It would be good if we could also provide thread names for the tokio runtimes that get created so that we can tell them apart in, say, prstat. Short names would be best; e.g., rt-http and rt-vm. |
Is there any further input on where we should start in terms of minimums/maximums on the number of worker threads we spawn for an instance? I was going to start with a minimum of 8, scaling to a max of however many vCPUs an instance has. This is obviously not perfect as processing needs for Crucible presumably scale with the disk count (and workload), not the number of guest CPUs. |
I don't have a strong opinion on this; 8 + vCPU count seems like a reasonable starting point. However, be aware that heavy Crucible work (encryption / decryption) is actually done in the Rayon thread pool, not Tokio! The Rayon thread pool can be configured with |
Because the global pool is somewhat challenging to initialize safely, I've filed oxidecomputer/crucible#1285 to cover that part of the problem. It will still be propolis' responsibility to bound the size of the tokio thread pool. |
Rather than letting Tokio go wild with its default of spawning worker threads equal to the number of visible host CPUs, we constrain that number to the number of guest vCPUs (down to a minimum of 8). Fixes oxidecomputer#686
Rather than letting Tokio go wild with its default of spawning worker threads equal to the number of visible host CPUs, we constrain that number to the number of guest vCPUs (down to a minimum of 8). Fixes oxidecomputer#686
No description provided.
The text was updated successfully, but these errors were encountered: