Process in T state does not want to die.....

[Eugene Grosbein]

29.11.2019 18:40, Konstantin Belousov wrote:

>>  From what I get from Konstantin is that this problem is due to memory 
>> pressure build by both ZFS and the buffercache used by UFS.
>> And the buffercache is waiting for some buffer memory to be able to do 
>> its work.
>>
>> If wanted I can try and put a ZFS fs on /dev/ggate0 so that any 
>> buffering would be in ZFS and not in UFS.
>>
>> But even with the patch I still now have:
>> root 3471   0.0  5.8  646768 480276  - TsJ  11:16  0:10.74 ceph-osd -i 0
>> root 3530   0.0 11.8 1153860 985020  - TsJ  11:17  0:11.51 ceph-osd -i 1
>> root 3532   0.0  5.3  608760 438676  - TsJ  11:17  0:07.31 ceph-osd -i 2
>> root 3534   0.0  3.2  435564 266328  - IsJ  11:17  0:07.35 ceph-osd -i 3
>> root 3536   0.0  4.8  565792 398392  - IsJ  11:17  0:08.73 ceph-osd -i 5
>> root 3553   0.0  2.3  362892 192348  - TsJ  11:17  0:04.21 ceph-osd -i 6
>> root 3556   0.0  3.0  421516 246956  - TsJ  11:17  0:04.81 ceph-osd -i 4
>>
>> And from procstat -kk below it looks like things are still stuck in 
>> bwillwrite, but now with another set of functions. I guess not writing 
>> an extattrib() but writing a file.
> Yes, it should resolve after you end the load that starves the buffer
> cache' dirty space.  Or wait some time until the thread gets its portion
> of share, which is unfair and could take a long time.
> 
> I will commit the VN_OPEN_INVFS patch shortly.

My system is ZFS-only. OTOH, it has vfs.zfs.arc_max=160g out of 360G RAM
plus it runs several bhyve instances that leak host's memory significantly
upto overflowing swap space (64G):

Nov 25 06:55:01 col02 kernel: swap_pager_getswapspace(32): failed

Is patch relevant for me?

Before update from 11.2-STABLE, there were no leaks.