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
>
>> Meanwhile if there is tons of recycles, you can damage control by
>> bumping kern.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:
#pragma D option dynvarsize=32m
profile:::profile-997
/execname == "find"/
{
@oncpu[stack(), "oncpu"] = count();
}
/*
* The p_flag & 0x4 test filters out kernel threads.
*/
sched:::off-cpu
/execname == "find"/
{
self->ts = timestamp;
}
sched:::on-cpu
/self->ts/
{
@offcpu[stack(30), "offcpu"] = sum(timestamp - self->ts);
self->ts = 0;
}
dtrace:::END
{
normalize(@offcpu, 1000000);
printa("%k\n%s\n%@d\n\n", @offcpu);
printa("%k\n%s\n%@d\n\n", @oncpu);
}
just leave it running as: dtrace -s script.d -o output
kill it after periodic finishes. it blindly assumes there will be no
other processes named "find" messing around.
> Bye,
> Alexander.
>
> --
> http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
> http://www.FreeBSD.org netch...@freebsd.org : PGP 0x8F31830F9F2772BF
>
--
Mateusz Guzik <mjguzik gmail.com>
