4 ms·

This always sounds good on paper and this is very common lore, but then when you get into production escalations a very common problem is a lot of software depe

This always sounds good on paper and this is very common lore, but then when you get into production escalations a very common problem is a lot of software depends on limits for autoconfiguration of thread pools and even several runtimes (go and java for example, at least .net is mentioned in the article), yes you can usually set them with a flag but people have to know this, communicate it, enforce it. Basically replace adhoc what limits is doing for you automatically configuration wise So this just all assumes you have a setup where all teams communicate the necessary information perfectly.. what happens in practice is workloads degrade at edge cases because there are 256 threads running for a thread pool instead of 4.

barrkel 2mo ago
Go is particularly hilarious because it will just go and create a thread for every hardware thread in your system (my home system has 192 hardware threads), just in case it needs to scale up. So tiny utilities, little network proxies and the like add up to thousands of threads + stacks etc. for very little load.
- maeln 2mo ago
  To be fair to Go, it is a very common "rule of thumb" for a lot of software that do parallelism to spawn as much thread as there are cores. A lot of library and software in various languages do this. This is used to be safe 99% percent of the time since almost all CPU had at most 16 cores/threads. So even on dual CPU platform it was not that big of a deal. Now that you can get ARM and x86 CPUs with hundreds of cores (although a lot of use-case for those is running VM which will only report a certain cpu count), this rule of thumb can cause issue. But most devs are not running on platform with hundreds of cores, and there is always the option to set the thread count, so I expect this pattern will linger on for a while.
running101 2mo ago
HPA uses limits for scaling decisions

barrkel 2mo ago

Go is particularly hilarious because it will just go and create a thread for every hardware thread in your system (my home system has 192 hardware threads), just in case it needs to scale up. So tiny utilities, little network proxies and the like add up to thousands of threads + stacks etc. for very little load.

maeln 2mo ago
To be fair to Go, it is a very common "rule of thumb" for a lot of software that do parallelism to spawn as much thread as there are cores. A lot of library and software in various languages do this. This is used to be safe 99% percent of the time since almost all CPU had at most 16 cores/threads. So even on dual CPU platform it was not that big of a deal. Now that you can get ARM and x86 CPUs with hundreds of cores (although a lot of use-case for those is running VM which will only report a certain cpu count), this rule of thumb can cause issue. But most devs are not running on platform with hundreds of cores, and there is always the option to set the thread count, so I expect this pattern will linger on for a while.

running101 2mo ago

HPA uses limits for scaling decisions