Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 21 Apr 2022 15:44:02 +0200
From:      Alexander Leidinger <Alexander@leidinger.net>
To:        Mateusz Guzik <mjguzik@gmail.com>
Cc:        Doug Ambrisko <ambrisko@ambrisko.com>, freebsd-current@freebsd.org
Subject:   Re: nullfs and ZFS issues
Message-ID:  <20220421154402.Horde.I6m2Om_fxqMtDMUqpiZAxtP@webmail.leidinger.net>
In-Reply-To: <CAGudoHEyCK4kWuJybD4jzCHbGAw46CQkPx_yrPpmRJg3m10sdQ@mail.gmail.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>

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

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

Quoting Mateusz Guzik <mjguzik@gmail.com> (from Thu, 21 Apr 2022=20=20
14:50:42=20+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=20=20
second=20night 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 second sl=
eep.

That would explain the behavior I see since I added the last jail=20=20
which=20seems to have crossed a threshold which triggers the slow=20=20
behavior.

Current=20status (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=20=20
default=20value on this system.

Bye,
Alexander.

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

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

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

iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmJhX6IACgkQEg2wmwP4
2IZTeA//cJhz26bByMcB3GGJiE1hbe/vkBg5GmXXecD5mD6BSDbBoMM3lA5IW/v5
a9JDus3iY+oeAhyJO5ig5znRwVkfpOhHbO9dFqIdp6mwIN1k2+91AMr6SMTEHhnu
cvlLVUnlhZeSLzW4ty79iKsLYXyheC06MMrHVawrJs/i22XOS4+zPyT33N/WNMLs
UGNqWFuyYw5+PQCGcX46NSbEZYiDLN9AMM9lXwY2RnY8ziX5JnW6lEU88OrW7O/v
F5Y2uDj1UPsmkPwsaVtblDpzpcI/bEoR2/YECSjX07kVJ/r5cLI9FMbAxBn4Nbyb
mKpYYYX+ORzmS9uKML/pZJUsATCM552AALU8LLtbUyZ2V09uOo3nsICdDbB8CAvi
A/E9acuGqQFbHE/iXQrU+U01GmRrb9A+OG7oYMHmMqQccmi5hDYWzXpGzrU/8jGU
J2q/32chB2czyYg9QT0U4KVKuxE2Gpn2Vxl60A1EmrLTtnbsbMugJIQOr2fpekYo
1BoFdqyUpfL5VP+GuPiTzCPikLWEAFk4v1wVpdd6vd0MMXcghyTZ9hXoWTAYW80V
xnSpT92sI/VoMyjcTjPAwevvdfbSKtSPOg2WKa3/XTJUKCn0m+x2LQwTydjO+olp
NP63zlpAwuIQzg46pNdX3PYCy+418Dwb0vh9JkoHKgPxfWsxe/0=
=OibP
-----END PGP SIGNATURE-----

--=_mCoQQKdVyX4TDmpIgE_NwAt--



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