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 BaldwinReceived 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