on 06/01/2014 13:14 Vladimir Sharun said the following:
> Dear Andriy and FreeBSD community,
> 
> I got the few minutes run for this dtrace hook; here's the output for 15 
> minutes run:
> 
> http://pastebin.com/pKm9kLwa
> 
> Does it explain something ?

The following makes me suspect a problem with L2ARC compression code.

              zfs.ko`l2arc_feed_thread+0x7d9
              kernel`fork_exit+0x9a
              kernel`0xffffffff8069ad6e
            95131

I am not sure if the buffers are leaked somehow or if they are actually in use.
It's one of the very few places where data buffers are allocated without
charging ARC.  In all other places it's quite easy to match allocations and
deallocations.  But in L2ARC it is not obvious that all buffers get freed or
when that happens.

>> on 04/01/2014 14:50 Vladimir Sharun said the following:
>> [snip]
>>> ARC: 28G Total, 2085M MFU, 20G MRU, 29M Anon, 1858M Header, 3855M Other
>> [snip]
>>> ITEM                   SIZE  LIMIT     USED     FREE      REQ FAIL SLEEP
>> [snip]
>>> zio_data_buf_131072: 131072,      0,  488217,       9,287155442,   0,   0
>>
>> I noticed a particular discrepancy between reported ARC usage and sizes of 
>> UMA
>> zones used by ZFS code:
>>
>> 488217 * 131072 = ~59GB right there.
>>
>> There are several possibilities for this discrepancy:
>> - bad accounting or reporting of ARC stats
>> - those 128K buffers being used in a special way and thus not accounted as 
>> ARC
>> - some sort of resource leak
>>
>> You could try to use DTrace to gather the stacks of all code paths that lead 
>> to
>> allocation of those buffers.  Something like:
>>
>> fbt::zio_data_buf_alloc:entry
>> /arg0 == 131072/
>> {
>> @[stack()] = count();
>> }
>>
>> This could be a start for understanding the issue.
>>


-- 
Andriy Gapon
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to