From nobody Tue Apr 26 06:15:45 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 1AC65199B589 for ; Tue, 26 Apr 2022 06:16:15 +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 4KnWq15250z3F5K for ; Tue, 26 Apr 2022 06:16:13 +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 064741D27; Tue, 26 Apr 2022 08:16:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1650953767; 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=hQ0yLqrV2AMBlfaeS7+FEklDYOzVM4GZgUbJ0qf/wMU=; b=MOGsWVgOiJPofwQxMt7QMVXI2tYOn/eXfsfvlYfb8kqPV1bcYsvTqF/evee0Md9D/6CKqc hlj5mPgCylm3+mS63CJRJpVwTN7sqDQ8KJ/SkCuwjrLiiiCBZVzKkwuSPtIGfvQ2YgCbzt AweEzrK3kgFO4KYo9+tCn8riOhu8XyjLx2hJSYUjGW7ZgWvH1x/7mZfdMj7WhVc0nI1P5m cTJbqPCexr0fC2UUyAEKNLtDctssJXfIFIqyNjo0ndu4wji39PThxCa/hiJIf//Wfe63Z2 Skg6x4mxA++RH8cB7NdgshhSK9dWVD5OM1FMDKx2dVvQrWRfAzUYh5IV2IIrnw== 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 AB81843E9; Tue, 26 Apr 2022 08:15:48 +0200 (CEST) Date: Tue, 26 Apr 2022 08:15:45 +0200 Message-ID: <20220426081545.Horde.IzWT3chMkImG5Hr28ZuCwFT@webmail.leidinger.net> From: Alexander Leidinger To: Eirik =?utf-8?b?w5h2ZXJieQ==?= Cc: 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> <20220422090439.Horde.TabULDW9aIeaNLxngZxdvvN@webmail.leidinger.net> <20220424195817.Horde.W5ApGT13KmR06W2pKA0COxB@webmail.leidinger.net> <20220425152727.Horde.YqhquyTW0ZM3HAbI1kyskic@webmail.leidinger.net> In-Reply-To: Accept-Language: de,en Content-Type: multipart/signed; boundary="=_M0tS0UKMgrrriOAIvn4fVPG"; 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: 4KnWq15250z3F5K X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=MOGsWVgO; 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)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; RCPT_COUNT_TWO(0.00)[2]; 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]; 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. --=_M0tS0UKMgrrriOAIvn4fVPG Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Eirik =C3=98verby (from Mon, 25 Apr 2022=20=20 18:44:19=20+0200): > On Mon, 2022-04-25 at 15:27 +0200, Alexander Leidinger wrote: >> Quoting Alexander Leidinger (from Sun, 24 >> Apr 2022 19:58:17 +0200): >> >> > Quoting Alexander Leidinger (from Fri, 22 >> > Apr 2022 09:04:39 +0200): >> > >> > > Quoting Doug Ambrisko (from Thu, 21 Apr >> > > 2022 09:38:35 -0700): >> > >> > > > 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 wou= ld >> > > > 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 >> > > using nocache in the nightly periodic runs. 4h instead of 12-24h >> > > (22 jails on this system). >> > > >> > > > On my laptop I set ARC to 1G since I don't use swap and in the pas= t >> > > > 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 and reduced arc reclaim settings (100, 1). I will check the >> > > runtime for the next 2 days. >> > >> > 9-10h runtime with the above settings (compared to 4h with nocache >> > and 12-24h without any patch and without nocache). >> > I changed the sysctls back to the defaults and will see in the next >> > run (in 7h) what the result is with just the patches. >> >> And again 9-10h runtime (I've seen a lot of the find processes in the >> periodic daily run of those 22 jails in the state "*vnode"). Seems >> nocache gives the best perf for me in this case. > > Sorry for jumping in here - I've got a couple of questions: > - Will this also apply to nullfs read-only mounts? Or is it only in > case of writing "through" a nullfs mount that these problems are seen? > - Is it a problem also in 13, or is this "new" in -CURRENT? > > We're having weird and unexplained CPU spikes on several systems, even > after tuning geli to not use gazillions of threads. So far our > suspicion has been ZFS snapshot cleanups but this is an interesting > contender - unless the whole "read only" part makes it moot. For me this started after creating one more jail on this system and I=20=20 dont't=20see CPU spikes (as the system is running permanently at 100%=20=20 and=20the distribution of the CPU looks as I would expect it). The=20=20 experience=20of Doug is a little bit different, as he experiences a high=20= =20 amount=20of CPU usage "for nothing" or even a dead-lock like situation.=20= =20 So=20I would say we see different things based on similar triggers. The nocache option for nullfs is affecting the number of vnodes in use=20= =20 on=20the system no matter if ro or rw. As such you can give it a try.=20=20 Note,=20depending on the usage pattern, the nocache option may increase=20= =20 lock=20contention. So it may or may not have a positive or negative=20=20 performance=20impact. Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_M0tS0UKMgrrriOAIvn4fVPG Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmJnjhAACgkQEg2wmwP4 2IY0Ew/+MAgJ6GkpOD+3jmRxFznSmnIGyVgOHVb6+vt+iuFXanPrNwKMutkHOsqz mFXMYfgyC7sCyC0zu6SMF0Tdv9b6JOb8TzSoyujjvLbdVAWL7ccozgFslQLyCGtk VFKmS+oB1/3gWQp3NwnrHdNVFxCfrqUcIGjJ+aKHP1hVi6LD9S0OYljQiys9ZKCI 90q8PCDd9qPl4vA3XGTmAqBpWYD3blYeTQNwl/YmH381pc6Sul5jD86QDETrCZUR LdCqukhtL7qdoSyJnHU4mSM+iXIynDGsBtid7z20YLTqrsrwWC3Oo8UtY8enkA67 mxBw4HBWxLHt1CU/YJ5Wc4wF2NIumCuM/F6xJmio4ZMWLfHBnQQuBO0HpYFstb09 yBGdfhVHYZcfSlVGjjGZ8vpoYO9js5yj3OPjgOXztjWsu1EZ0RFwSoVs0LRHgCdD lj4gpW0OVIn0pOZBLB2zfDIOrv4mBoXEJ8mShpqrKS1Mb6Hz0yFxCUvL8wxUSwZY AVQzASquJcFp1bm6NZsRx98gXPHCssiY9M+8P5CKTGj4Fi+NTBq204s9uqY+Ze8G /jCv1Kdm1jvteelZnKIdugFQk8eNJF1LzFkshIaq8YrByHkk1wqm4Mfjup6DG42T 5/iKqZStd4V5TTCMba8AhAYMI4Sel5RT1Utn951sWrqHRwdcL/A= =gYPL -----END PGP SIGNATURE----- --=_M0tS0UKMgrrriOAIvn4fVPG--