From nobody Fri Apr 22 07:04:39 2022 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 38B891A80C05 for ; Fri, 22 Apr 2022 07:04:49 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kl54v5Fvfz4dyT for ; Fri, 22 Apr 2022 07:04:47 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from outgoing.leidinger.net (p5b165562.dip0.t-ipconnect.de [91.22.85.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK)) by mailgate.Leidinger.net (Postfix) with ESMTPSA id 88CBF7EF; Fri, 22 Apr 2022 09:04:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1650611084; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=b1LWFXIqHVfRbZtCN42iEdLyBsyrwD80Fzi9VGeqmO8=; b=K+/PUFvm5x7ny63JSiDl1uyCLTlruQzEr9s9g/633zFkEM81Of4ZZxkMAcKoJgY2tSe/bE QoQTdAcwg+UtGInLllye4aMX2pPMVm23llK+bDhnQeHVN4c11EOHx9BRGCgNOCnpN7EPW0 Z0ZGbqhoLadFtXHa2gyQ4pr4h/YAcxV8bzQYrqL+0H+8rs8Hq3ezBQ6d9bKFJVQZtpvIPQ fpdOvL+lBWTow3GZVwSpNo78qrSP2srV7v2Xx1VijscOW0KkC/LfMDWGy+DH7WRqKlyz2s 8YeSVOMbUaRBmzn+ClvyVIAysd7TQuvpct/yb6emhvvSiD5lOuC+BbfwJ+RXTA== Received: from webmail.leidinger.net (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (Client did not present a certificate) by outgoing.leidinger.net (Postfix) with ESMTPS id 715F14683; Fri, 22 Apr 2022 09:04:40 +0200 (CEST) Date: Fri, 22 Apr 2022 09:04:39 +0200 Message-ID: <20220422090439.Horde.TabULDW9aIeaNLxngZxdvvN@webmail.leidinger.net> From: Alexander Leidinger To: Doug Ambrisko Cc: Mateusz Guzik , freebsd-current@freebsd.org Subject: Re: nullfs and ZFS issues References: <20220420113944.Horde.5qBL80-ikDLIWDIFVJ4VgzX@webmail.leidinger.net> <20220421083310.Horde.r7YT8777_AvGU_6GO1cC90G@webmail.leidinger.net> <20220421154402.Horde.I6m2Om_fxqMtDMUqpiZAxtP@webmail.leidinger.net> In-Reply-To: Accept-Language: de,en Content-Type: multipart/signed; boundary="=_OOmCLJCGKh7pUIN2ebU7UkJ"; protocol="application/pgp-signature"; micalg=pgp-sha256 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 X-Rspamd-Queue-Id: 4Kl54v5Fvfz4dyT X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b="K+/PUFvm"; dmarc=pass (policy=quarantine) header.from=leidinger.net; spf=pass (mx1.freebsd.org: domain of Alexander@leidinger.net designates 2a00:1828:2000:313::1:5 as permitted sender) smtp.mailfrom=Alexander@leidinger.net X-Spamd-Result: default: False [-6.10 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[91.22.85.98:received] X-ThisMailContainsUnwantedMimeParts: N 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 (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 (from Thu, 21 Apr 2022 > | 14:50:42 +0200): > | > | > On 4/21/22, Alexander Leidinger 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--