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 >> during replacing disks in a raidz by bigger ones. Long story short, >> check top -s if you have vnlru running for a long period at high >> CPU... If yes increase kern.maxvnodes (I increased to 10 times). Note, >> we should improve the admin page in the FAQ, the vnlru entry could >> need a little bit more hints and explanations. >> >> If you encounter the same issue we have probably introduced a change >> somewhere with an unintended side effect. >> >> Bye, >> Alexander. >> > > Hi! > I'm seeing this as well, on 13-CURRENT. I updated a computer from the > last January snapshot (30 or 31 of January, I can't remember) and it > seems disk IO is very slow. I remember having a svn checkout taking a > very long time, with the SVN process pegged at 100% according to top. I > can't see the vnlru process running though, but I haven't looked > closely, and I haven't tried the maxvnodes workaround. Something has > changed though. > This is systems using ZFS, both mirror and single disk. Gstat shows > disks are mostly idle. > > I know this is a lousy bug report, but this, and the feeling that things > are slower than usual, is what I have for now. > Regards Hi! I did some more digging. In short, disabling options COVERAGE and 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 in the new zfs dataset. This is in no way scientific, since I only ran the test once on each kernel, and using something on the network means I'm susceptible to varying network speeds and so on, but. In this specific scenario, using a kernel without those options, it's about 3 times faster than with, at least on the computer where I ran the tests. I noticed in the commit log that the coverage and kcov options has been disabled again, albeit for a different reason. Perhaps they should remain off, unless the extra runtime overhead can be disabled in runtime, similar to witness. Regards -- NiclasReceived on Sun Feb 10 2019 - 19:55:22 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:20 UTC