glib 2.88.1 and or gobjec-introspection 1.86 causing vnode exhaustion on 10.9.5 ?!

[René J.V. Bertin]

Hi,

I just upgraded my glib2 and gobject-introspection ports to current versions, and seem to have run into a very annoying side-effect.

I'm running OS X 10.9.5 on a 16Gb MBP 8.1 with a 2nd gen i7, still not exactly a *slow* machine but already I noticed afterwards that rebuilding ffmpeg took surprisingly long, and that load averages went as high as 16 or more while I use only 4 parallel jobs. I think the total build took 45 minutes (using gcc13 [sic!], -O3 and LTO; I cannot remember if that's actually a normal build duration).

Then, I tried another build, this time using clang-17, and it failed because the kernel file table was full. Bumping kern.maxvnodes had no effect, and since the machine was up for 68 days already I rebooted.

After the boot, I monitored vnode usage, and saw it rising rapidly enough that I bumped maxvnodes to 5Mb (from 257k ...), and ended up with I think over 2Mb vnodes in use.

The only real change I'd made was the glib2 and gobject-introspection upgrades, so I reactivated to the previous port versions (2.78.4 and 1.72.0) and rebooted again.

Now, with my usual session restored, my current vnode usage is back to something more reasonable; 64324.

I don't want to lose more time trying to re-activate the newer versions and see if the vnode issue returns, but can this somehow be related?

I did not rebuild any of those ports' dependents, but from what I've seen that should not be necessary.

Can this observation make sense ... does it make sense? From what I understand, maxvnodes is the max. number of files that can be cached ... but `vnodes` doesn't seem to go down when I flush the file cache.

FWIW, the glib2 and gobject-introspection ports are built +universal, using clang-17 .

BTW, what's the cost of increasing kern.maxvnodes (i.e. what's the footprint of 1 entry of that file table)?

Thanks for any thoughts or feedback!