Hello. Guido Falsi wrote on 2023/07/10 18:01: > This resonates with something I have observed from time to time on my build > machine. > Especially when using a big ccache (32 GiB or more, is what I can testify > about), but also when building ports with a big number of files like the > teTeX, it sometimes runs out of vnodes and the everything grind to an halt. > Raigin maxvnodes to very high numbers helps a lot. > > I now have this is sysctl.conf: > kern.maxvnodes=4194304 > > Maybe this is related, and anyway something worth looking into IMHO. > Maybe simply rising the default maxvnodes for machines with a lot of RAM (my > machine has 48 GiB) could help.
The current value of my machine is, # sysctl hw.physmem kern.maxvnodes hw.physmem: 34254241792 kern.maxvnodes: 620655 Default value. Probably. Charlie Li wrote on 2023/07/10 23:09: > This doesn't appear disk IO-related, since I've hardly seen any intensive > disk activity while pkg-add(8) executes, but the CPU usage has shot up > significantly for no apparent benefit. > > I filed https://github.com/freebsd/pkg/issues/2156 to track this. I think pkg-add uses libarchive, but the cause does not exist inside pkg, and libarchive in general may be the cause of the slowdown. For example, chromium seems to do small increments of disk access while browsing, but if I'm doing firefox source extraction on the side (make -C /usr/ports/www/firefox extract), chromium waits a long time. This occurs not only during source extraction, but also in the middle of some kind of find in periodic daily. So I'm thinking that libarchive is not the cause, but something closer to os or hardware, but I can't narrow down the conditions. Now a WD hard drive that poweronhours in smart returns 38423 may be bad :) Anyway, I know that there are people who feel the same way :) I'll consider increasing kern.maxvnodes a bit and seeing how it goes. Regards,
