"Oddness" in head since around r343678 or so
Niclas Zeising
zeising+freebsd at daemonic.se
Sun Feb 10 20:55:23 UTC 2019
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
--
Niclas
More information about the freebsd-current
mailing list