Limit max number of threads according to the machine.
gravityvi opened this issue · comments
Piscina accepts any value for max number of threads that could be large enough for the machine the code is running on. It would be better if this is somewhat controlled and there is a warning when users try to overuse the resources available in the local machine.
I believe this can be covered through documentation, as having a warning can be somehow noisy and bring false positives easily.
Would you like to send a PR for it? 🙂
@metcoder95 Wouldn't it be better to limit the number of max threads based on the machine's cores and give out a warning?
The documentation change should be a must to advise of the consequences of running more threads than cores.
Though, spawning more threads than cores isn't something bad that can kill your app. Sadly, having more threads than cores will cause each thread to steal time from the other (including the parent one), and depending on your workload and the pieces of work the implementation does it might be what you want to, is really rare a thread really uses 100% of CPU (although not impossible).
Printing a warning might be a good idea, but I'm worried here about the level of noise it can introduce (which can lead to users asking to find a way to silence the deprecation warning).
@metcoder95 Thanks for the detailed explanation. I will raise a PR for the documentation change 😄
@metcoder95 So what would be your recommendation here? Is cores - 1 a sensible recommendation for thread settings? (so that there is still one core left for main thread).
It heavily depends on your workload, if your main thread does not do I/O but just coordinates the threads; most likely you'll benefit from having the same number of threads as per CPUs.
If you are unsure, you can start with the defaults from Piscina (which is cpus * 1.5, e.g. 4 * 1.5 = 6) which is a good number to start with and pivot from there.
It is important to remark to benchmark your workload and seek how it behaves over different combination; as well as to seek which combinations keeps your threads busy but coping with the load and how often they become idle.
@kibertoad @metcoder95 if I recall correctly, @jasnell mentioned in one of his talks that the potentially useful number of worker threads could be up to cpus^2.
This issue has been marked as stale because it has been opened 30 days without activity. Remove stale label or comment or this will be closed in 5 days.
This issue was closed because it has been stalled for 5 days with no activity.