nixbuild.net tries to automatically select optimal resources for each build, minimizing both build time and unused CPU time. What it means for you as a user is that the builds will be as cheap and fast as possible, without you having to do anything.
Each build can be allocated 1 to 16 CPUs, depending on its ability to make use of multiple CPUs. If nixbuild.net can't make an informed decision on resource allocation, the build will be assigned 2 CPUs.
The builds will be allocated as much memory as needed, but if a build uses an excessive amount of memory it will be cancelled. The exact memory limits are not yet formalised. In nixbuild.net, the memory allocated to a build is used both for the build's RAM requirements, but also for the storage of build output (both intermediate and final).
How Does it Work?¶
The automatic resource optimization works in two steps:
When a Nix derivation is submitted to nixbuild.net, we look for similar derivations that have been built on nixbuild.net before. A heuristic approach is used, where derivations are compared based on package names and version numbers. This approach can be improved in the future, by looking at more parts of the derivations, like dependencies and build scripts.
A number of the most recent, most similar derivations are selected. We then analyze the build data of those derivations. Since we have developed a secure sandbox specifically for running Nix builds, we're also able to collect a lot of data about the builds. One metric that is collected is CPU utilization, which lets us make predictions about how well a build would scale, performance-wise, if it was given more CPUs.
We also look at metrics about the historic memory usage to make sure the new build is allocated enough memory.