Well, we eventually upgraded to 1.14.4 (OTP25), and I remember expecting it to improve because dependency analysis is said to be improved, but the load average stays at 4 for 16 virtual cores.

Ironically, I found this thread when trying to analyze the same problem four years later. I just didn’t check back then when we upgraded, but I see load averages remain where they were, I guess.

Something to note. Average core load of 4 does not mean only 4 cores are used

It could be that 16 are used but they spend most of their time on IO or idling or blocked by a lock somewhere. This is a not too rare thing to happen.

CPU load is a pretty flawed metric these days to evaluate how much you saturate the number of cores.

See CPU Utilization is Wrong and Linux Load Averages: Solving the Mystery as starting points

Elixir will use as many cores as there are scheduler threads available which defaults to the number of cores in your system.

Elixir will try to parallelize the compilation of individual files as much as possible, but any file’s compile time dependencies will have to be compiled before it which can limit the number of files that can be compiled in parallel. If you have many such dependencies in your project the compiler will not be able to use all cores.

There has been optimizations in recent Elixir releases that reduces the number of compile time dependencies so make sure you are running the latest version. @wojtekmach has also written about how to reduce the dependencies in your projects: https://dashbit.co/blog/speeding-up-re-compilation-of-elixir-projects and https://dashbit.co/blog/rewriting-imports-to-aliases-with-compilation-tracers.

If you run iex you will get an output such as:

Erlang/OTP 23 [erts-11.0.3] [source] [64-bit] [smp:12:12] [ds:12:12:10] [async-threads:1] [hipe]

Interactive Elixir (1.12.0-dev) - press Ctrl+C to exit (type h() ENTER for help)

The number in [smp:12:12] will say how many scheduler threads are being used.

Yes, maybe I can.

While I don’t have control over the CI machine, maybe I could change the job script so that pulls in the elixir tarball, builds it, and then let it use that one instead of the one we have deployed. Maybe.