Am 2023-08-15 23:29, schrieb Mateusz Guzik:
On 8/15/23, Alexander Leidinger <alexan...@leidinger.net> wrote:
Am 2023-08-15 14:41, schrieb Mateusz Guzik:
With this in mind can you provide: sysctl kern.maxvnodes
vfs.wantfreevnodes vfs.freevnodes vfs.vnodes_created vfs.numvnodes
vfs.recycles_free vfs.recycles
After a reboot:
kern.maxvnodes: 10485760
vfs.wantfreevnodes: 2621440
vfs.freevnodes: 24696
vfs.vnodes_created: 1658162
vfs.numvnodes: 173937
vfs.recycles_free: 0
vfs.recycles: 0
New values after one rund of periodic:
kern.maxvnodes: 10485760
vfs.wantfreevnodes: 2621440
vfs.freevnodes: 356202
vfs.vnodes_created: 427696288
vfs.numvnodes: 532620
vfs.recycles_free: 20213257
vfs.recycles: 0
Meanwhile if there is tons of recycles, you can damage control by
bumping kern.maxvnodes.
What's the difference between recycles and recycles_free? Does the above
count as bumping the maxvnodes?
Looks like there are not much free directly after the reboot. I will
check the values tomorrow after the periodic run again and maybe
increase by 10 or 100 so see if it makes a difference.
If this is not the problem you can use dtrace to figure it out.
dtrace-count on vnlru_read_freevnodes() and vnlru_free_locked()? Or
something else?
I mean checking where find is spending time instead of speculating.
There is no productized way to do it so to speak, but the following
crapper should be good enough:
[script]
I will let it run this night.
Bye,
Alexander.
--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org netch...@freebsd.org : PGP 0x8F31830F9F2772BF
