!RROtHmAaQIkiJzJZZE:nixos.org

NixOS Infrastructure

418 Members
Next Infra call: 2024-07-11, 18:00 CEST (UTC+2) | Infra operational issues backlog: https://github.com/orgs/NixOS/projects/52 | See #infra-alerts:nixos.org for real time alerts from Prometheus.128 Servers

Load older messages


SenderMessageTime
19 May 2026
@hexa:lossy.networkhexa (signing key rotation when)they were never rolled out from nixos/infra before in that case10:37:47
@hexa:lossy.networkhexa (signing key rotation when)this will eventually sync up10:38:01
@vcunat:matrix.orgvcunatBut these aren't new, are they? They've been in the builder set for a long time, IIRC.10:39:03
@hexa:lossy.networkhexa (signing key rotation when)oh, this is in the hetzner/customer user 🤔10:39:06
@hexa:lossy.networkhexa (signing key rotation when)we don't manage keys in that user10:39:33
@hexa:lossy.networkhexa (signing key rotation when)we only manage them for root10:39:51
@vcunat:matrix.orgvcunatI mean, I'm not really interested in putting significant work into darwin stuff. I'll gladly leave that to you or others.10:40:19
@hexa:lossy.networkhexa (signing key rotation when)uh-huh10:40:53
@vcunat:matrix.orgvcunatThough it's one lock-file shared for all kinds of machines, so I guess it's better not to let the real state drift too much.10:41:14
@vcunat:matrix.orgvcunat

BTW

root@mac05.ofborg.org | error: config contains the wrong home directory for hydra-queue-builder, aborting activation
10:43:20
@hexa:lossy.networkhexa (signing key rotation when)can you file an issue for that?10:52:31
@vinceff:matrix.orgVinceff joined the room.16:47:30
@amadaluzia:4d2.orgamadaluzia changed their profile picture.20:56:29
20 May 2026
@c0ba1t:matrix.orgCobalt

Hey, I was looking into optimizations for build scheduling to account for substitution cost and was wondering how large (in terms of number/total size of derivations) the nix store was on builder nodes. This is mainly intended to make some guestimates about how expensive the query of "Which subset of a package's build graph is present on a builder node and how large (in total file size) is that subset?" is. My personal builders have varied from 250K-1M but they are almost certainly smaller/less used than the public builders.

I have looked through the data in the public Grafana instance but could not find an applicable metric. Could you please, if it is available somewhere, include this metrics in the Prometheus Instance for the NixOS Infra?

Alternatively, could someone with access to the nodes please look it up on a few builder nodes for me? It should be queriable via the sqlite DB (nix shell nixpkgs#sqlite -c sqlite3 /nix/var/nix/db/db.sqlite 'select count(*), sum(narSize) from ValidPaths' or (more expensive, without file size) by counting the store paths directly with ls -l /nix/store | wc -l)

11:18:19
@k900:0upti.meK900 Something that was brought up before is that you can just do a bloom filter over store hashes 11:32:45
@k900:0upti.meK900 It ends up on the order of a few kilobytes for a very good hit rate 11:33:06
@k900:0upti.meK900 The real problem is that requires an additional agent on the workers 11:33:22
@c0ba1t:matrix.orgCobalt

I know, I plan to do some research on this for my baechelor thesis. iirc you or hexa (signing key rotation when) broght it up when I asked for relevant issues before in the offtopic channel. The main thing for me here was to not just count store paths though but instead the total size of the store paths (as , e.g., firefox-bin is heavier than harfbuzz).

My main plan here was to make a prototype with an extra agent/nix-scheduler-hook and use the results from testing there to propose changes to hydra queue runner later.

11:38:49
@c0ba1t:matrix.orgCobalt *

I know, I plan to do some research on this for my baechelor thesis. iirc you or hexa (signing key rotation when) broght it up when I asked for relevant issues before in the offtopic channel. The main thing for me here was to not just count store paths though but instead the total size of the store paths (as , e.g., firefox-bin is heavier than harfbuzz).

My main plan here was to make a prototype with an extra agent/nix-scheduler-hook and use the results from testing there to propose changes to hydra queue runner later. The number/total size of paths here was to make some estimates here about actual costs of, e.g., asking the daemon for the subset of paths in the store.

11:39:57
@c0ba1t:matrix.orgCobalt *

I know, I plan to do some research on this for my baechelor thesis. iirc you or hexa (signing key rotation when) broght it up when I asked for relevant issues before in the offtopic channel. The main thing for me here was to not just count store paths though but instead the total size of the store paths (as , e.g., firefox-bin is heavier than harfbuzz).

My main plan here was to make a prototype with an extra agent/nix-scheduler-hook and use the results from testing there to propose changes to hydra queue runner later. The number/total size of paths here was to make some estimates here about actual computational cost of, e.g., asking the daemon for the subset of paths in the store.

11:40:07
@c0ba1t:matrix.orgCobalt *

I'm aware of the issues with just tagging it on the existing daemon, I plan to do some research on this for my baechelor thesis. iirc you or hexa (signing key rotation when) broght it up when I asked for relevant issues before in the offtopic channel. The main thing for me here was to not just count store paths though but instead the total size of the store paths (as , e.g., firefox-bin is heavier than harfbuzz).

My main plan here was to make a prototype with an extra agent/nix-scheduler-hook and use the results from testing there to propose changes to hydra queue runner later. The number/total size of paths here was to make some estimates here about actual computational cost of, e.g., asking the daemon for the subset of paths in the store.

11:41:37
@hexa:lossy.networkhexa (signing key rotation when)
[root@elated-minsky:~]# nix shell nixpkgs#sqlite -c sqlite3 /nix/var/nix/db/db.sqlite 'select count(*), sum(narSize) from ValidPaths'
391244|5632213988352
[root@sleepy-brown:~]# nix shell nixpkgs#sqlite -c sqlite3 /nix/var/nix/db/db.sqlite 'select count(*), sum(narSize) from ValidPaths'
335188|5232269242216
[root@goofy-hopcroft:~]# nix shell nixpkgs#sqlite -c sqlite3 /nix/var/nix/db/db.sqlite 'select count(*), sum(narSize) from ValidPaths'
828294|12762811007880
[root@hopeful-rivest:~]# nix shell nixpkgs#sqlite -c sqlite3 /nix/var/nix/db/db.sqlite 'select count(*), sum(narSize) from ValidPaths'
157509|2004835377096
11:56:04
@hexa:lossy.networkhexa (signing key rotation when)those are our linux builders, the first two x86_64-linux, the last two aarch64-linux11:57:39
@c0ba1t:matrix.orgCobaltThank you a lot!11:58:08
@hexa:lossy.networkhexa (signing key rotation when) and our gc logic 11:58:42
@c0ba1t:matrix.orgCobaltThank you for pointing me to the configurations, I was aware of that to some degree (searching for the metrics initially led me to the system configurations). The 500GB limit for a GC run is presumably to ensure that the GC is not locking the store for too long?12:01:36
@hexa:lossy.networkhexa (signing key rotation when)yeah, gc is not free and if we keep some outputs around for reuse that's good too12:03:27
@hexa:lossy.networkhexa (signing key rotation when)we might eventually migrate to nix-fast-gc in a bit12:03:59
@hexa:lossy.networkhexa (signing key rotation when) that'll fix us 12:04:12
@hexa:lossy.networkhexa (signing key rotation when)Redacted or Malformed Event12:04:23

Show newer messages


Back to Room ListRoom Version: 6