| 4 Dec 2025 |
 aloisw | getting the spew to stop is very simple: just patch out the print statement | 16:13:20 |
| aloisw | Unfortunately I can't seem to reproduce the spew (obviously without the patch alluded to above, which has in fact not been written) any more, so it's really hard to debug this :( | 16:14:48 |
|  isabel changed their profile picture. | 16:42:02 |
 rosssmyth | They make money by vendoring their customers' test suite into SQLite's test suite to "guarantee" that they do not break. So most configurations that are actually used should be covered. | 16:49:02 |
| rosssmyth | Which is why it is impossible to view or replicate their full test suite | 16:49:50 |
 toonn | Huh, that's an interesting approach to monetizing open source. | 16:51:09 |
| rosssmyth | They also do normal support & NRE stuff | 16:51:45 |
 raitobezarius | In reply to @aloisw:julia0815.de
Unfortunately I can't seem to reproduce the spew (obviously without the patch alluded to above, which has in fact not been written) any more, so it's really hard to debug this :( I think I can provide you with an example | 16:53:15 |
| aloisw | If that example is "run nix-eval-jobs on nixpkgs", then that's not much help. It's also where I have seen it in the past but now I got zero of them. | 16:55:14 |
| raitobezarius | In reply to @aloisw:julia0815.de
If that example is "run nix-eval-jobs on nixpkgs", then that's not much help. It's also where I have seen it in the past but now I got zero of them. And concurrent n-e-j? | 16:56:08 |
| raitobezarius | But not on nixpkgs was my plan | 16:56:15 |
| raitobezarius | I think if you take a look at the AFNix infra evaluation CI scheme, there's like up to 5 nej on large NixOS systems and it still seems to reproduce there | 16:56:46 |
| aloisw | 4 workers on nixpkgs, which I have determined at some point in the past to get the most throughput. | 16:56:55 |
| raitobezarius | Large closures made of small files should probably hit the thing? | 16:57:05 |
| raitobezarius | In reply to @aloisw:julia0815.de
4 workers on nixpkgs, which I have determined at some point in the past to get the most throughput. But that's only one nej instance right? If you do 4 workers * N | 16:57:21 |
| aloisw | Yeah maybe contention is more with 4N workers which should roughly have the same effect. | 16:58:35 |
| aloisw | --store /tmp/teststore shit that might have done it… | 16:59:19 |
| raitobezarius | :d | 17:03:21 |
| aloisw | 16 workers on non-durable btrfs gives weirder behaviour at least: still no busy messages, but they saturate neither CPU nor disk. | 17:04:42 |
| aloisw | Hm that doesn't seem to work either, what filesystem are you on? | 17:12:58 |
| aloisw | (and disk, maybe something can be done with dm-delay) | 17:14:14 |
| raitobezarius | bcachefs rn | 18:17:52 |
| raitobezarius | but the target disk systems are on xfs iirc? | 18:17:59 |
| aloisw | 
Download Yeah that's a bit different from what I was expecting. | 19:28:30 |
| raitobezarius | so it's an implicit lock on the WAL? | 19:43:27 |
| aloisw | It's the checkpointer blocking everything. | 19:49:19 |
| aloisw | And the weird thing is that I only got this in the run where I made reads slow as well. | 19:49:50 |
| raitobezarius | why is it weird in your opinion? | 19:50:36 |
| aloisw | Well either it's a coincidence or the problem is that the checkpointer is blocked on reads. | 19:51:15 |
| aloisw | Currently I'm doing another run to figure it out. | 19:51:46 |
