Date: Sun, 10 Feb 2019 21:55:16 +0100 From: Niclas Zeising <zeising+freebsd@daemonic.se> To: Alexander Leidinger <Alexander@Leidinger.net>, "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net>, current@freebsd.org Subject: Re: "Oddness" in head since around r343678 or so Message-ID: <51739ca5-7662-6040-1da3-01f08e85bbb8@daemonic.se> In-Reply-To: <bbd8e47c-6490-b453-f1f7-0be74fb0201c@daemonic.se> References: <201902071536.x17FaPtI051105@pdx.rh.CN85.dnsmgr.net> <168cc6f6518.27fa.fa4b1493b064008fe79f0f905b8e5741@Leidinger.net> <bbd8e47c-6490-b453-f1f7-0be74fb0201c@daemonic.se>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2019-02-10 16:35, Niclas Zeising wrote: > On 2019-02-08 10:27, Alexander Leidinger wrote: >> Hi, >> >> I recently noticed some generic slowness myself. I experienced this=20 >> during replacing disks in a raidz by bigger ones. Long story short,=20 >> check top -s if you have vnlru running for a long period at high=20 >> CPU... If yes increase kern.maxvnodes (I increased to 10 times). Note,= =20 >> we should improve the admin page in the FAQ, the vnlru entry could=20 >> need a little bit more hints and explanations. >> >> If you encounter the same issue we have probably introduced a change=20 >> somewhere with an unintended side effect. >> >> Bye, >> Alexander. >> >=20 > Hi! > I'm seeing this as well, on 13-CURRENT.=C2=A0 I updated a computer from= the=20 > last January snapshot (30 or 31 of January, I can't remember) and it=20 > seems disk IO is very slow.=C2=A0 I remember having a svn checkout taki= ng a=20 > very long time, with the SVN process pegged at 100% according to top.=C2= =A0 I=20 > can't see the vnlru process running though, but I haven't looked=20 > closely, and I haven't tried the maxvnodes workaround.=C2=A0 Something = has=20 > changed though. > This is systems using ZFS, both mirror and single disk.=C2=A0 Gstat sho= ws=20 > disks are mostly idle. >=20 > I know this is a lousy bug report, but this, and the feeling that thing= s=20 > are slower than usual, is what I have for now. > Regards Hi! I did some more digging. In short, disabling options COVERAGE and=20 options KCOV made my test case much faster. My test: boot system create a new zfs dataset (zroot/home/test in my case) time a checkout of https://svn.freebsd.org/base/head, putting the files=20 in the new zfs dataset. This is in no way scientific, since I only ran the test once on each=20 kernel, and using something on the network means I'm susceptible to=20 varying network speeds and so on, but. In this specific scenario, using a kernel without those options, it's=20 about 3 times faster than with, at least on the computer where I ran the=20 tests. I noticed in the commit log that the coverage and kcov options has been=20 disabled again, albeit for a different reason. Perhaps they should=20 remain off, unless the extra runtime overhead can be disabled in=20 runtime, similar to witness. Regards --=20 Niclas
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51739ca5-7662-6040-1da3-01f08e85bbb8>