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/ >> { >> _at_[stack()] = count(); >> } >> >> This could be a start for understanding the issue. >> -- Andriy GaponReceived on Mon Jan 06 2014 - 10:55:18 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:46 UTC