3 ms·

> - On Amazon ECS, provide the CPU share count explicitly; Shenandoah likes more threads Can you explain this further? I'm missing some connection here between

• WJW 5y ago
  Not OP, but many systems will scale the amount of threads based on the core count in your system. So on a 32-core system you might have 32 GC threads. On ECS (and many other container orchestrators) when you set some CPU allocation like perhaps 0.2 CPU, your process will still "see" all the CPUs present in the system but the process will just not be scheduled if the allocation for this time period has been used up. This could cause Shenandoah to over-allocate GC threads and eat into your CPU allocation.
• enduku 5y ago
  Based on the number of CPU cores on the machine, Shenandoah sets up its threads. JVM will see only one CPU core if the number of CPU shares for the container is not set explicitly[0]. In that case, Shenandoah will use only single parallel thread to do the collections, and the entire application may crash. [0]https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_environment https://docs.aws.amazon.com/AmazonECS/latest/developerguide/...
  • mwcampbell 5y ago
    Ah, right. I wish ECS had an option to expose all of an EC2 instance's underlying cores to a container with no constraints. In that case, the scheduler could use the memoryReservation setting to figure out which containers can fit on which instances.