Date: Tue, 15 Aug 2023 23:29:45 +0200 From: Mateusz Guzik <mjguzik@gmail.com> To: Alexander Leidinger <Alexander@leidinger.net> Cc: current@freebsd.org Subject: Re: Speed improvements in ZFS Message-ID: <CAGudoHEP8TrSzz0TL-PsOx0WNc7z3042wJk-jhhVwhTyJ0VEQQ@mail.gmail.com> In-Reply-To: <ed1f82dd26d3cc9ec9cc16505109ec40@Leidinger.net> References: <61ca9df1b15c0e5477ff51196d0ec073@Leidinger.net> <CAGudoHG5Fgg4184SsXhzqYRR7VPaBXZoirGvyRyJX5ihX5YG-A@mail.gmail.com> <ed1f82dd26d3cc9ec9cc16505109ec40@Leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 8/15/23, Alexander Leidinger <Alexander@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 Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
> http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF
>
--
Mateusz Guzik <mjguzik gmail.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGudoHEP8TrSzz0TL-PsOx0WNc7z3042wJk-jhhVwhTyJ0VEQQ>