which may be a reasonable thing to do, but itll increase complexity a lot

yeah i do

nomad would still have issues with the ram amounts, i would have to keep memory down to 4GB then increase memory max above 8 to 12 which is a really bad idea because nomad schedules based on memory not memory max

i may just have to split it up, nix-daemon, hydra-http and hydra-evaluator

i dont have space for swap anywhere currently unfortunately, when i clean up the 1TB skyhawks i can put it there but i need to move data of them onto the 4tb wd reds

i would still like to somehow make hydra not eval everything at once, but i would have to know a lot more c++ to do that

In reply to @magic_rb:matrix.redalder.org

i would still like to somehow make hydra not eval everything at once, but i would have to know a lot more c++ to do that

for flakes? how would that work

In reply to Linux Hackerman
If you're on nixos, I'd suggest trying zramSwap.enable = true in any case

well when i push a change hydra will start evaluating everything at once anyway, it has no notion of "hey maybe evaluations can choke the system too"

ah ok so that may be a path forward

In reply to @magic_rb:matrix.redalder.org

ah ok so that may be a path forward

    # evaluator_initial_heap_size is basically equivalent to GC_INITIAL_HEAP_SIZE and defaults to 384MiB
    # evaluator_max_memory_size is… "If our RSS exceeds the maximum, exit. The master will start a new process.". defaults to 4096 (I assume MiB)
    # evaluator_workers is how many parallel evaluator workers are used. defaults to 1
    # max_concurrent_evals defines how many evaluations are run concurrently. defaults to 4
    extraConfig = ''
      email_notification = 1
      evaluator_max_memory_size = 4096
      evaluator_initial_heap_size = ${toString (2 * 1024 * 1024 * 1024)}
      max_output_size = ${toString (16 * 1024 * 1024 * 1024)}
      max_concurrent_evals = 3
      evaluator_workers = 4