Arvados

Arvados is written with the expectation that a container request's requested RAM reflects the amount of RAM that will actually be used by the container. And this is a nice way to work, since if you do this, it means Arvados can always select the cheapest available instance type for your container, even if the set of instance types changes over time.

However, users do not always have a strong idea of how much RAM their container is likely to take. Usage may seem to vary wildly by input. Sometimes instead of committing to how much RAM the container needs, they commit to how much they're willing to spend: they write a RAM request based on the list of available instance types, rather than the job's actual needs.

This causes mismatched expectations. A user writes a workflow step that requests 32GiB RAM, expecting that step to be dispatched to (as an AWS example) m5.2xlarge. However, since Crunch adds its own overhead to this number, it ends up dispatching to a larger instance type—assuming one is available. This can be costly.

If a container request comes in with a RAM request that exactly matches a configured instance type, assume the user wrote against the instance type list and accommodate them. Crunch should dispatch to that same instance type (assuming it meets all other runtime constraints). When the container is dispatched, Crunch should let it use all the RAM minus however much RAM it thinks it needs for its own supporting services.