Re: OpenZFS and L2ARC

From: John Baldwin <jhb_at_FreeBSD.org>
Date: Wed, 9 Sep 2020 12:26:24 -0700
On 9/9/20 1:30 AM, Stefan Esser wrote:
> Am 09.09.20 um 08:46 schrieb Stefan Esser:
>> Am 09.09.20 um 00:45 schrieb Graham Perrin:
>>> Recalling 
>>> <https://lists.freebsd.org/pipermail/freebsd-current/2020-March/075661.html>, 
>>> on 28/03/2020 15:17,28/03/2020 15:17, Allan Jude wrote:
>>>
>>>  >> …
>>>  >>
>>>  >> Basically 'arc' was converted to a subtree.
>>>  >>
>>>  >> We should add some backwards compat sysctls to cover some of
>>>  >> these renames etc so configs and scripts don't break etc.
>>
>> This is not possible for quite a number of sysctls, since there is
>> no simple 1:1 mapping for many of them.
>>
>>
>> And there is an annoyance that I had noticed before but now have
>> tracked down:
>>
>> $ time sysctl kstat.zfs.misc.dbufs | wc
>>     55327 2047031 16333472
>>
>> real    0m16,446s
>> user    0m0,055s
>> sys    0m16,397s
>>
>> Somebody decided to put a complete list of dbufs under this sysctl
>> and thus querying "kstat.zfs.misc" takes that long (16 seconds to
>> generate 16 MB of output on my system), even if only a few other
>> values in "kstat.zfs.misc" are needed.
>>
>> I do not know whether there is any chance to get that debug output
>> moved out of the "misc", e.g. into a new "debug" sub-tree. I'm afraid,
>> that on Linux there are scripts that expect it under this name.
>>
>> If it is not acceptable to the upstream, we should locally modify the
>> sysctl tree to move that variable out of "misc", IMHO. (While not
>> taking much time, "kstat.zfs.misc.dbgmsg" should also be relocted to
>> a "debug" sub-tree, IMHO ...)
>>
>> zfs-stats needs tens of values from "misc", and if they are not all
>> added individually to the Kstat array, this will limit the response
>> time to any zfs-stats invocation.
>>
>> It is not too hard to add the new variables in zfs-stats and to
>> adapt the calculations to derive meaningful values to display.
>>
>> But if it always takes 16 seconds to generate any output, I'm not
>> likely to use it too often ...
> 
> Update: I have created a fork of zfs-stats to work on:
> 
> https://github.com/stesser/zfs-stats
> 
> Initial change is to work around the long delay mentioned above and to
> use the correct name for the vdev cache size variable and to display
> the size, data contents and the corresponding compression factor of the
> compressed L2ARC.
> 
> I'll create pull requests to inform the upstream of these changes.

A simple fix might be to use CTLFLAG_SKIP so that you only invoke the
expensive sysctls if you request them by name, but not if you request
the 'kstat.zfs' tree.

-- 
John Baldwin
Received on Wed Sep 09 2020 - 17:26:26 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:25 UTC