| 1 May 2026 |
 swarsel | what are the best ways to get insight on where the memory footprint of an evaluation comes from? i noticed that my builder constantly ran out of memory when trying to build one of my configurations - I then built it locally and noticed that it takes 96G to evaluate 😅 the machine has 20 microvm guests which probably accounts for some of this, but I still think that I must be using some antipatterns that increase it to such amounts ^^ | 07:10:51 |
 ---m--- | Redacted or Malformed Event | 12:30:50 |
| 4 May 2026 |
 phaer | The "Zero Hydra Failures" campaign for the upcoming 26.05 has started: https://github.com/NixOS/nixpkgs/issues/516381 🎉
It's a shared effort to try and squash as many build errors & other bugs as possible, during the release process. 🐛
The issue description provides a nice intro as well as technical details on how to find staff to work on. I also found https://zh.fail/ useful. 📉
Posting this as there were people motivated to hack together at the May meetup. I personally will be on vacation this time 🏝️ Have fun! :) | 13:03:23 |
| phaer | the simplest, most primitive thing that comes to mind is NIX_SHOW_STATS=1 which lets nix print eval stats, including memory usage. A good start to confirm whether it's microvms, could be to eval each of them separately, and/or the toplevel closure without the vms (e.g. commented-out for a moment). | 13:06:24 |
| phaer | a classic time -v in front of nix eval can also be useful here.
There's some support for profiling, but IMO they are mostly useful for speed. I personally don't find the profile helps me much to understand memory evals
| 13:09:10 |
| swarsel | yeah NIX_SHOW_STATS is where i got the number from (totalBytes) - I think the issue is that I am cross-referencing other nodes in nearly each one of them - i am not sure how it affects the whole closure, but could be that each microvm in essence then has to eval itself + all other nodes? | 13:09:36 |
| swarsel | * yeah NIX_SHOW_STATS is where i got the number from (totalBytes) - I think the issue is that I am cross-referencing other nodes in nearly each one of them - i am not sure how it affects the whole closure, but could be that each microvm in essence then has to eval itself + all other nodes? i guess that would scale exponentially. interestingly, when i removed a single microvm, i noticed nearly no difference in the memory usage | 13:10:22 |
| phaer | Ah, i was about to write: yes, cross-references between nixos closures should be avoided as much as possible, if you care about memory usage IMO. | 13:10:28 |
| swarsel | yeah i will have to do that now, until now that only manifested in eval time taken which i did not care about, but now this needs fixing 😅 | 13:11:21 |
| 5 May 2026 |
| swarsel | well i looked into it a little and found that the biggest offender were a fer malformed lines that generated thousands of nftables rules for each wireguard peer - fixing that took it down from >90G to now about 20G. much, better, but still too much for my liking :p
all my cross node evaluations are already done once when filling my globals output - that iterates over all config and aggregates some global definitions. that is a mechanism that i really do not want to get rid of, i think it is super useful. also i thought that this kind of eval would not be very costly since nearly nothing needs to be accessed in the first place.
for my client pc config without any microvms, it takes me 9G - what is the memory usage for a usual nixosConfig for you guys? | 14:05:43 |
| swarsel | * well i looked into it a little and found that the biggest offender were a fer malformed lines that generated thousands of nftables rules for each wireguard peer - fixing that took it down from >90G to now about 20G. much, better, but still too much for my liking :p
all my cross node evaluations are already done once when filling my globals output - that iterates over all config and aggregates some global definitions. that is a mechanism that i really do not want to get rid of, i think it is super useful. also i thought that this kind of eval would not be very costly since nearly nothing needs to be accessed in the first place.
for my client pc config without any microvms, it takes me 9G - what is the memory usage for a usual nixosConfig for you people? | 14:07:59 |
| swarsel | * well i looked into it a little and found that the biggest offender were a fer malformed lines that generated thousands of nftables rules for each wireguard peer - fixing that took it down from >90G to now about 20G (that surprised me a lot!). much, better, but still too much for my liking :p
all my cross node evaluations are already done once when filling my globals output - that iterates over all config and aggregates some global definitions. that is a mechanism that i really do not want to get rid of, i think it is super useful. also i thought that this kind of eval would not be very costly since nearly nothing needs to be accessed in the first place.
for my client pc config without any microvms, it takes me 9G - what is the memory usage for a usual nixosConfig for you people? | 14:13:31 |
| swarsel | * well i looked into it a little and found that the biggest offender were a fer malformed lines that generated thousands of nftables rules for each wireguard peer - fixing that took it down from >90G to now about 20G (that surprised me a lot!). much, better, but still too much for my liking :p
all my cross node evaluations are already done once when filling my globals output - that iterates over all config and aggregates some global definitions. that is a mechanism that i really do not want to get rid of, i think it is super useful. also i thought that this kind of eval would not be very costly since nearly nothing needs to be accessed in the first place. the evaluation of globals by itself (which is around 35 configs I guess) takes around 4G, which seems reasonable?
for my client pc config without any microvms, it takes me 9G - what is the memory usage for a usual nixosConfig for you people? | 14:44:24 |
| 18 Nov 2023 |
|  spacesbot - keeps a log of public NixOS channels joined the room. | 14:08:18 |
| spacesbot - keeps a log of public NixOS channels | 15:00:22 |
| 19 Nov 2023 |
 Krezzlu | Redacted or Malformed Event | 09:46:57 |
|  ZXGU joined the room. | 10:58:29 |
| 20 Nov 2023 |
| phaer changed the room topic to "nixos.at - Nix(OS) meetups in Graz, Vienna and elsewhere in Austria; in German and English." from "nixos.at - Nix(OS) meetups in Graz, Vienna and elsewhere in Austria; in German and English (Formerly #nixos-vienna) ". | 12:49:24 |
| 3 Dec 2023 |
|  hakmark joined the room. | 10:05:29 |
| 7 Dec 2023 |
|  Rasmus changed their profile picture. | 10:29:10 |
| 13 Dec 2023 |
|  admu joined the room. | 07:11:25 |
| admu changed their display name from adam mccartney to admu. | 07:12:00 |
| 25 Dec 2023 |
|  ruru4143 changed their display name from ruru4143 to ruru[📞:4143]. | 13:38:28 |
|  xro changed their display name from xro to xrotest. | 19:51:26 |
| xro changed their display name from xrotest to xro2. | 19:51:48 |
| xro changed their display name from xro2 to xro. | 19:55:32 |
| 26 Dec 2023 |
|  domih changed their profile picture. | 11:03:55 |
| 27 Dec 2023 |
|  jstsmthrgk changed their display name from jstsmthrgk to jstsmthrgk [DECT 5651]. | 09:26:09 |
| 1 Jan 2024 |
| ruru4143 changed their display name from ruru[📞:4143] to ruru4143. | 00:47:46 |
| 2 Jan 2024 |
| jstsmthrgk changed their display name from jstsmthrgk [DECT 5651] to jstsmthrgk. | 11:40:28 |
