| 4 Dec 2025 |
 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 |
| raitobezarius | i wonder if the checkpointer blocked on reads makes sense in the transaction isolation model of sqlite | 19:51:44 |
