!siOVEzpzgLbkHTjpmA:numtide.com

NixOS Archivists

56 Members
Taking care of NixOS historical build artifacts and GC. Meeting notes: https://pad.lassul.us/nixos-cache-gc For self-hosting, see #binary-cache-selfhosting:nixos.org 18 Servers

Load older messages


SenderMessageTime
4 Mar 2024
@flokli:matrix.orgflokliIt'd a r5a.2xlarge, but I'm not 100% it was this all the time13:52:15
@flokli:matrix.orgflokli* It's a r5a.2xlarge, but I'm not 100% it was this all the time13:52:22
@flokli:matrix.orgflokliYou can probably correlate the meeting notes with the terraform config in the nixos infra repo13:52:49
@flokli:matrix.orgflokliAh, it's been that instance size all the time, we only bumped the disk at some point13:55:46
@flokli:matrix.orgflokliThe ingestion was running on multiple NARs in parallel, so we were saturating all cores13:56:04
@nh2:matrix.orgnh2
In reply to @nh2:matrix.org
flokli: What kind of machine was it? From my memory XZ decompression is ~60 MB/s/core (where 1 xz invocation does not scale beyond 1 core)
I just did a quick test on 620lqprbzy4pgd2x4zkg7n19rfd59ap7-chromium-unwrapped-108.0.5359.98, there xz -d on output of tar | xz -9 is 120 MB/s, saturating 1 core.
13:59:09
@nh2:matrix.orgnh2
In reply to @nh2:matrix.org
flokli: What kind of machine was it? From my memory XZ decompression is ~60 MB/s/core (where 1 xz invocation does not scale beyond 1 core)
* I just did a quick test on 620lqprbzy4pgd2x4zkg7n19rfd59ap7-chromium-unwrapped-108.0.5359.98 on AMD 5950X, there xz -d on output of tar | xz -9 is 120 MB/s, saturating 1 core.
13:59:55
@flokli:matrix.orgflokliI think the thing that took a horrible long time was some chromium debuginfo outputs14:05:25
@flokli:matrix.orgflokliI don't have the exact store path anymore14:05:32
@flokli:matrix.orgfloklibut yeah, overall xz is the main timesink14:05:44
@flokli:matrix.orgflokliNot sure how much any of this matters though. If we want to start serving NAR files from elsewhere, we need to check Nix doesn't do stupid things if FileSize and FileHash from the .narinfo do differ with what we serve14:07:20
@flokli:matrix.orgflokliAnd we need to send it with the same compression algo too, at least until we'd feel confident updating the NARInfo files.14:08:10
@flokli:matrix.orgflokliAnd this is all work on top of doing all the work to determine which NAR files to delete / deep-freeze.14:08:37
@edef1c:matrix.orgedef
In reply to @flokli:matrix.org
And this is all work on top of doing all the work to determine which NAR files to delete / deep-freeze.
i'm pretty close to done on that to be clear, i'm just kind of low-motivation over the past few days
14:55:34
5 Mar 2024
@hexa:lossy.networkhexahttps://github.com/NixOS/infra/pull/39714:24:17
6 Mar 2024
@edef1c:matrix.orgedef set a profile picture.23:28:24
7 Mar 2024
@samrose:matrix.orgsamrose joined the room.03:25:38
@edef1c:matrix.orgedef Jonas Chevalier: fwiw i seem to be wrong about the ETags 07:20:08
@edef1c:matrix.orgedefthough if we turn on versioning we might want to tweak the bucket inventory exports07:21:03
@edef1c:matrix.orgedefand while we can't turn off versioning, we can suspend versioning08:46:20
@edef1c:matrix.orgedefthere could be things i'm missing, but i think it's fine to turn it on08:46:55
@zimbatm:numtide.comJonas Chevalierohh that's good news09:02:13
@zimbatm:numtide.comJonas Chevalierok so we can delete the narinfos and not worry about re-generating them09:03:04
@edef1c:matrix.orgedefi'm poking around a bit at the releases bucket, looks like we have like four nixos-15.09-small releases that are just … missing a store-paths.xz?09:42:39
@delroth:delroth.net@delroth:delroth.net Btw archivists folks, analysis request for whenever one of you has time: I think it would be useful to know the answer to "if we kept the last N channel bumps for each active channel in something else than S3, how much would we save in bandwidth". Do you already have the tooling to do this kind of logs analysis? 09:51:43
@delroth:delroth.net@delroth:delroth.net Basically, figuring out how much of the bandwidth costs is driven by the short head vs. the long tail. 09:53:06
@delroth:delroth.net@delroth:delroth.net * Basically, figuring out how much of the bandwidth costs are driven by the short head vs. the long tail. 09:53:16
@edef1c:matrix.orgedefi think i can throw together a join or two for that, and it's a query i've been wanting to put together09:56:27
@flokli:matrix.orgflokliYeah, we have the bucket logs in a format that allows to query for that10:40:10
@edef1c:matrix.orgedef flokli: if you'd like to take this on: you know how to run weave and stuff, and you can grab fetchroots from my CL 10:41:40

Show newer messages


Back to Room ListRoom Version: 10