4 Mar 2024 |
flokli | It'd a r5a.2xlarge, but I'm not 100% it was this all the time | 13:52:15 |
flokli | * It's a r5a.2xlarge, but I'm not 100% it was this all the time | 13:52:22 |
flokli | You can probably correlate the meeting notes with the terraform config in the nixos infra repo | 13:52:49 |
flokli | Ah, it's been that instance size all the time, we only bumped the disk at some point | 13:55:46 |
flokli | The ingestion was running on multiple NARs in parallel, so we were saturating all cores | 13:56:04 |
nh2 | 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 | 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 | I think the thing that took a horrible long time was some chromium debuginfo outputs | 14:05:25 |
flokli | I don't have the exact store path anymore | 14:05:32 |
flokli | but yeah, overall xz is the main timesink | 14:05:44 |
flokli | Not 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 serve | 14:07:20 |
flokli | And 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 | And this is all work on top of doing all the work to determine which NAR files to delete / deep-freeze. | 14:08:37 |
edef | 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 | https://github.com/NixOS/infra/pull/397 | 14:24:17 |
6 Mar 2024 |
| edef set a profile picture. | 23:28:24 |
7 Mar 2024 |
| samrose joined the room. | 03:25:38 |
edef | Jonas Chevalier: fwiw i seem to be wrong about the ETags | 07:20:08 |
edef | though if we turn on versioning we might want to tweak the bucket inventory exports | 07:21:03 |
edef | and while we can't turn off versioning, we can suspend versioning | 08:46:20 |
edef | there could be things i'm missing, but i think it's fine to turn it on | 08:46:55 |
Jonas Chevalier | ohh that's good news | 09:02:13 |
Jonas Chevalier | ok so we can delete the narinfos and not worry about re-generating them | 09:03:04 |
edef | i'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 | 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 | 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 | * Basically, figuring out how much of the bandwidth costs are driven by the short head vs. the long tail. | 09:53:16 |
edef | i think i can throw together a join or two for that, and it's a query i've been wanting to put together | 09:56:27 |
flokli | Yeah, we have the bucket logs in a format that allows to query for that | 10:40:10 |
edef | 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 |