Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 22 Apr 2022 09:04:39 +0200
From:      Alexander Leidinger <Alexander@leidinger.net>
To:        Doug Ambrisko <ambrisko@ambrisko.com>
Cc:        Mateusz Guzik <mjguzik@gmail.com>, freebsd-current@freebsd.org
Subject:   Re: nullfs and ZFS issues
Message-ID:  <20220422090439.Horde.TabULDW9aIeaNLxngZxdvvN@webmail.leidinger.net>
In-Reply-To: <YmGIiwQen0Fq6lRN@ambrisko.com>
References:  <Yl31Frx6HyLVl4tE@ambrisko.com> <20220420113944.Horde.5qBL80-ikDLIWDIFVJ4VgzX@webmail.leidinger.net> <YmAy0ZNZv9Cqs7X%2B@ambrisko.com> <20220421083310.Horde.r7YT8777_AvGU_6GO1cC90G@webmail.leidinger.net> <CAGudoHEyCK4kWuJybD4jzCHbGAw46CQkPx_yrPpmRJg3m10sdQ@mail.gmail.com> <20220421154402.Horde.I6m2Om_fxqMtDMUqpiZAxtP@webmail.leidinger.net> <YmGIiwQen0Fq6lRN@ambrisko.com>

next in thread | previous in thread | raw e-mail | index | archive | help
This message is in MIME format and has been PGP signed.

--=_OOmCLJCGKh7pUIN2ebU7UkJ
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Quoting Doug Ambrisko <ambrisko@ambrisko.com> (from Thu, 21 Apr 2022=20=20
09:38:35=20-0700):

> On Thu, Apr 21, 2022 at 03:44:02PM +0200, Alexander Leidinger wrote:
> | Quoting Mateusz Guzik <mjguzik@gmail.com> (from Thu, 21 Apr 2022
> | 14:50:42 +0200):
> |
> | > On 4/21/22, Alexander Leidinger <Alexander@leidinger.net> wrote:
> | >> I tried nocache on a system with a lot of jails which use nullfs,
> | >> which showed very slow behavior in the daily periodic runs (12h runs
> | >> in the night after boot, 24h or more in subsequent nights). Now the
> | >> first nightly run after boot was finished after 4h.
> | >>
> | >> What is the benefit of not disabling the cache in nullfs? I would
> | >> expect zfs (or ufs) to cache the (meta)data anyway.
> | >>
> | >
> | > does the poor performance show up with
> | > https://people.freebsd.org/~mjg/vnlru_free_pick.diff ?
> |
> | I would like to have all the 22 jails run the periodic scripts a
> | second night in a row before trying this.
> |
> | > if the long runs are still there, can you get some profiling from it?
> | > sysctl -a before and after would be a start.
> | >
> | > My guess is that you are the vnode limit and bumping into the 1=20=20
>=20second sleep.
> |
> | That would explain the behavior I see since I added the last jail
> | which seems to have crossed a threshold which triggers the slow
> | behavior.
> |
> | Current status (with the 112 nullfs mounts with nocache):
> | kern.maxvnodes:               10485760
> | kern.numvnodes:                3791064
> | kern.freevnodes:               3613694
> | kern.cache.stats.heldvnodes:    151707
> | kern.vnodes_created:         260288639
> |
> | The maxvnodes value is already increased by 10 times compared to the
> | default value on this system.
>
> I've attached mount.patch that when doing mount -v should
> show the vnode usage per filesystem.  Note that the problem I was
> running into was after some operations arc_prune and arc_evict would
> consume 100% of 2 cores and make ZFS really slow.  If you are not
> running into that issue then nocache etc. shouldn't be needed.

I don't run into this issue, but I have a huge perf difference when=20=20
using=20nocache in the nightly periodic runs. 4h instead of 12-24h (22=20=
=20
jails=20on this system).

> On my laptop I set ARC to 1G since I don't use swap and in the past
> ARC would consume to much memory and things would die.  When the
> nullfs holds a bunch of vnodes then ZFS couldn't release them.
>
> FYI, on my laptop with nocache and limited vnodes I haven't run
> into this problem.  I haven't tried the patch to let ZFS free
> it's and nullfs vnodes on my laptop.  I have only tried it via

I have this patch and your mount patch installed now, without nocache=20=20
and=20reduced arc reclaim settings (100, 1). I will check the runtime=20=20
for=20the next 2 days.

Your mount patch to show the per mount vnodes count looks useful, not=20=20
only=20for this particular case. Do you intend to commit it?

Bye,
Alexander.

--=20
http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild@FreeBSD.org  : PGP 0x8F31830F9F2772BF

--=_OOmCLJCGKh7pUIN2ebU7UkJ
Content-Type: application/pgp-signature
Content-Description: Digitale PGP-Signatur
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmJiU4YACgkQEg2wmwP4
2IbOog//UdLh0K5ti6ozpLt2s7aj7u71uwYtvloew6wL2RD0BQTzDMDUni0ttv49
XCKnz3fHjW4nraKJ1JXY5VAwbNzEDd+y4QowiO7qxM97K6GRyMfpfVJoCHdrBq2v
TCdjKKhuy7/gq96u5ko7cQUc4bbO6LCsC6Uja4S2HeEvRn/dQGROlzjQabbkV0NJ
3NS5A0HrPaZvkMTP9IXYEmItrVA1rwlndvy37AAMqXrsYfx+32PRLj8bbT2flXgh
CTbVRYg4iKXRI03OzfVdg1t+73tBrZRT9GfnlvaZf/tU0Q5+/fgVqPszAK58aLpR
HBSSeOTI1ZAVzYL078Xvd+CxmZwuYp3mJ/VlrOjH8wYVtlEG86en+gIZW3OjzxQI
E4YlWSjjoEmTuHcTkiOwe7m0nfbaIpB6pvwouKv3/DdbeJK1nrHlftqXY7qDVb0z
VVSMaJKwGQWoKYqWmB/NcBg/G1EkkJ1W3241dc3XcRVve84hDVOyfvOcOaiptST5
fOFZaUZbL8V1IgZB4I4oMQlWpNHiKUoTFsdRCNQ52fyNlNpmGLlrg/npk9s+27FM
ZwtywCP02ibeK67X+Hy/CInEJE7J2cCJDNI4jenNTkGEM+8+BlWBdRMYzHOnOEfI
Q5BUC8sfgbClQEw/941H2U7uSq2e8VJ8vM5lL5Si86Rx/QqtQ+8=
=gJu9
-----END PGP SIGNATURE-----

--=_OOmCLJCGKh7pUIN2ebU7UkJ--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20220422090439.Horde.TabULDW9aIeaNLxngZxdvvN>