You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
By default, the tokio runtime will spawn a number of worker threads equal to the number of visible logical CPUs it finds on the system. No instance should ever be able to make use of all that CPU (especially since it has its own separate threads for driving the guest vCPUs), so it would make sense to limit the number of threads created by the tokio runtime.
The text was updated successfully, but these errors were encountered:
Related to this, Crucible's use of the rayon crate means it too is creating a bunch of worker threads. If propolis is making thread scaling decisions, it should probably help Crucible with the task too.
By default, the tokio runtime will spawn a number of worker threads equal to the number of visible logical CPUs it finds on the system. No instance should ever be able to make use of all that CPU (especially since it has its own separate threads for driving the guest vCPUs), so it would make sense to limit the number of threads created by the tokio runtime.
The text was updated successfully, but these errors were encountered: