title: How many threads/processes to create in an ECS task
body: <p>A c5.2xlarge instance has 8 vCPU. If I run os.cpu_count() (Python) or std::thread::hardware_concurrency() (C++) they each report 8 on this instance. I assume the underlying hardware is probably a much bigger machine, but they are telling me what I have available to me, and that seems useful and correct.</p>
  
  <p>However, if my ECS task requests only 2048 CPU (2 vCPU), then it will still get 8 from the above queries on a c5.2xlarge machine. My understanding is Docker is going to limit my task to only using "2 vCPU worth" of CPU, if other busy tasks are running. But it's letting me see the whole instance.</p>
  
  <p>It seems like this would lead to tasks creating too many threads/processes. 
   For example, if I'm running 2048 CPU tasks on a c5.18xlarge instance, each task will think it has 72 cores available. They will all create way too many threads/processes overall; it will work but be inefficient.</p>
  
  <p>What is the best practice here? Should programs somehow know their ECS task reservation? And create threads/processes according to that? That seems good except then you might be under-using an instance if it's not full of busy tasks. So I'm just not sure what's optimal there.</p>
  
  <p>I guess the root issue is Docker is going to throttle the total amount of CPU used. But it cannot adjust the number of threads/processes you are using. And using too many or too few threads/processes is inefficient.</p>
  
  <p>See discussion of <a href="https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ContainerDefinition.html" rel="noreferrer">cpu usage in ECS docs</a>.</p>
  
  <p>See also this long blog post: <a href="https://goldmann.pl/blog/2014/09/11/resource-management-in-docker/" rel="noreferrer">https://goldmann.pl/blog/2014/09/11/resource-management-in-docker/</a></p>