On Wed, Sep 17, 2014 at 5:13 PM, Steven Hartland <[email protected]> wrote:
> ----- Original Message ----- From: "Matthew Ahrens via illumos-zfs" < > [email protected]> > > With regards to buffers being allocated by arc_get_data_buf() I can't see >>> a path by which ARC will prevent a new buffer being allocated even when >>> arc_evict_needed(). >>> >>> >> It won't, but it will evict an existing buffer, thus freeing up memory for >> the new one. >> > > So just to confirm, the expected behaviour given a sudden burst of writes > when we're already tight on memory is that arc_get_data_buf calls > arc_evict(...) which removes cached data, which then gets reused > as a dirty data buffer? > > Yes. > If so we should see a large amount hits to the arc_evict:entry probe > with recycle followed by arc__evict hits. Yes. > > > If thats the case can't we hit min ARC but yet still claim new buffers? If >>> so we can suddenly demand up to 10% of the system memory all of which >>> may required VM to page before it can provide said memory. >>> >>> >>> Sure, the ARC can grow up to the minimum size without restriction. Is >> your >> ARC below the minimum size? >> > > Not sure Karl, could you confirm the size of ARC when the issue triggers? > > If the ARC size is at min or above, I'm wondering if we're simply not > successfully > evicting cache data in preference for write data when we're expecting > possibly > to due to hash lock misses? > Hash lock misses shouldn't be able to prevent us from evicting enough data. If one buffer's hash lock is held, we will move on to the next one. It would be extremely surprising if a large percent of all buffers are locked at the same time. --matt > > Karl when you see stalls are you seeing increasing mutex and > recycle misses? > sysctl kstat.zfs.misc.arcstats.mutex_miss > sysctl kstat.zfs.misc.arcstats.recycle_miss > > If this is the case could be that we're hitting contention between writes > triggering arc_evict directly and arc_reclaim_thread doing a cleanup? > > Regards > Steve >
_______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
