Re: Speed improvements in ZFS

Am 2023-08-15 23:29, schrieb Mateusz Guzik:
> 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

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 Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild@FreeBSD.org  : PGP 0x8F31830F9F2772BF