ZFS v15 slowness

[Martin Matuska]

 Ok, after running for a longer time, I can confirm that the stat()
speedup does not make the problem go away.
It is priority-related. If I have the problematic tasks running with a
nice >0, the system responds quickly.

It looks like more that maybe rc.subr was changed in a way that my
tinderbox daemon does not start with a lower priority anymore, so the
behaviour will be probably the same on pre-v15 and this makes this issue
probably not ZFS-v15-related or not even ZFS related at all.

The system slowness is overall, not only ZFS - also reaction of the
shell, too.

Dňa 24. 7. 2010 23:11, Pawel Jakub Dawidek  wrote / napísal(a):
> On Fri, Jul 23, 2010 at 12:47:13PM +0200, Martin Matuska wrote:
>>  To my experience, processes spend more time in zio (as of top).
>>
>> When there is a lot of FS activity the system responsiveness goes down
>> (filesystem reacts slowly or gets stallish).
>> A good example is my tinderbox system - when tinderbox does a lot of
>> small ports (heavy ZFS activity, untarring of many files and compiling,
>> searching for changed files, etc.) the system shows a stallish behaviour
>> in disk reads and my shell reacts slowly. [...]
> This looks like priority problem. What kernel threads consume most CPU
> time when if feel slowdown? Do you have compression enabled on loaded
> datasets? I'd try lowering priority of the guilty thread and see what
> happen.
>
>> [...] With the stat and rrwlock
>> patch it responds slightly better as it did before v15. The question is,
>> why.
>>
>> The affected system is core i7, amd64, 8GB ram, 2x750GB sata2 drives in
>> a ZFS mirror.
>> vm.kmem_size="6G"
>> vfs.zfs.arc_max="4G"
>>
>> Anyway, I would vote for these patches, maybe including ABE (it doesn't
>> hurt).
> I'd prefer to address performance problem with v15 first and then merge
> stat(2) speed up changes, especially that with stat(2) patch it is
> harder to reproduce.
>