9127f5bbc3
When using a binary cache store, the queue runner receives NARs from the build machines, compresses them, and uploads them to the cache. However, keeping multiple large NARs in memory can cause the queue runner to run out of memory. This can happen for instance when it's processing multiple ISO images concurrently. The fix is to use a TokenServer to prevent the builder threads to store more than a certain total size of NARs concurrently (at the moment, this is hard-coded at 4 GiB). Builder threads that cause the limit to be exceeded will block until other threads have finished. The 4 GiB limit does not include certain other allocations, such as for xz compression or for FSAccessor::readFile(). But since these are unlikely to be more than the size of the NARs and hydra.nixos.org has 32 GiB RAM, it should be fine. |
||
|---|---|---|
| doc | ||
| src | ||
| tests | ||
| .gitignore | ||
| bootstrap | ||
| configure.ac | ||
| COPYING | ||
| dev-shell | ||
| hydra-module.nix | ||
| INSTALL | ||
| Makefile.am | ||
| README.md | ||
| release.nix | ||
| version | ||
To start hacking on Hydra, run:
$ ./dev-shell
$ ./configure $configureFlags --prefix=/opt/hydra
$ make
$ make install
Or, if you just want to build from source (on x86_64-linux):
$ nix-build -A build.x86_64-linux release.nix