2 ms·
>> If you are going to represent ‘jobs’ or tasks as threads, and you need potentially 100s or 1000s of those, it just won’t scale - the overhead is too high. T
by marktangotango 10y ago
>> If you are going to represent ‘jobs’ or tasks as threads, and you need potentially 100s or 1000s of those, it just won’t scale - the overhead is too high.
This seems to be an indictment against containerization (ie docker, kubernetes, etc). How can a single machine, even with containers, scale out if this is true? Do people advocating docker and similar technologies not understand or recognize that their containers should only utilize y threads (where y = (total threads per machine)/(number of containers hosted on that machine))? I personally have never heard this mentioned as a consideration when deploying docker, for example.
- ecnahc515 10y agoThe advantages of containers are multidimensional. The benefit of running multiple processes on a single node is not solely to increase utilization of a given machine but to also gain advantages in deployment, etc. Schedulers can take what's being mentioned here into account. You can say "I need at least 2 cores but would like up to 8" or "I need guaranteed 8 cores, evict lower priority containers if necessary" to ensure your containers aren't fighting over resources . You can also classify machines for certain types of workloads and then specify certain containers should run on a particular class of node. Not all container platforms handle this, but Kubernetes does at least.
- smarterclayton 10y agoAnd as we add improved resource management and tuning to Kubernetes you gain those improvements without having to change your deployment pipeline - just like when a compiler gets better you get more performance for "free".