When copying files from UFS to ZFS, performance decreases quickly to a small fraction of the transfer rate of disks. The problem seems to be that caching of files on UFS decreases the available memory so much that ZFS decreases ARC size to the minimum and starts to throttle writes. Fix: I've managed to get better performance by modifying arc_memory_throttle to include v_cache_count in addition to v_free_count to the number of available pages, and increasing vm.v_cache_min and vm.v_cache_max so that more cached file data is included in v_cache_count instead of v_inactive_count. Here's a patch to sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c: With this patch, vfs.zfs.arc_min=671088640, vm.v_cache_min=300000 and vm.v_cache_max=400000, performance is adequate and I haven't seen a single increase of kstat.zfs.misc.arcstats.memory_throttle_count. This still doesn't solve the problem that ZFS decreases ARC size when reading from UFS. One way to fix that would be to implement a configurable maximum limit for the amount of cached file data for UFS, like vfs.zfs.arc_max for ZFS. Another way to prevent ARC from decreasing is increasing vfs.zfs.arc_min when copying data from a UFS partition and decreasing it to the original value after all data is copied. However, vfs.zfs.arc_min can't be changed with sysctl, so that approach requires two reboots. Perhaps it should be made possible to change vfs.zfs.arc_min without requiring a reboot?--QMBaLa9nyItJOj4yUfKY1ZzQyj5kNnXR6a847TysjUYXQdfM Content-Type: text/plain; name="file.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="file.diff" --- arc.c.orig 2010-05-08 17:53:38.343964308 +0300 +++ arc.c 2010-05-08 17:57:34.756952644 +0300 @@ -3516,7 +3516,8 @@ { #ifdef _KERNEL uint64_t inflight_data = arc_anon->arcs_size; - uint64_t available_memory = ptoa((uintmax_t)cnt.v_free_count); + uint64_t available_memory = ptoa((uintmax_t)cnt.v_free_count + + (uintmax_t)cnt.v_cache_count); static uint64_t page_load = 0; static uint64_t last_txg = 0; How-To-Repeat: Mount a ZFS filesystem and a UFS filesystem. Copy large files from UFS to ZFS. Wait until top(1) shows that there is little memory free and that kstat.zfs.misc.arcstats.size has decreased to vfs.zfs.arc_min. Observe the bad performance and the continuous rapid increase of kstat.zfs.misc.arcstats.memory_throttle_count.
Responsible Changed From-To: freebsd-bugs->freebsd-fs Over to maintainer(s).
Responsible Changed From-To: freebsd-fs->pjd I'll take this one.
Author: avg Date: Fri Sep 17 07:14:07 2010 New Revision: 212780 URL: http://svn.freebsd.org/changeset/base/212780 Log: zfs arc_reclaim_needed: more reasonable threshold for available pages vm_paging_target() is not a trigger of any kind for pageademon, but rather a "soft" target for it when it's already triggered. Thus, trying to keep 2048 pages above that level at the expense of ARC was simply driving ARC size into the ground even with normal memory loads. Instead, use a threshold at which a pagedaemon scan is triggered, so that ARC reclaiming helps with pagedaemon's task, but the latter still recycles active and inactive pages. PR: kern/146410, kern/138790 MFC after: 3 weeks Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c ============================================================================== --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c Fri Sep 17 04:55:01 2010 (r212779) +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c Fri Sep 17 07:14:07 2010 (r212780) @@ -2161,10 +2161,10 @@ arc_reclaim_needed(void) return (0); /* - * If pages are needed or we're within 2048 pages - * of needing to page need to reclaim + * Cooperate with pagedaemon when it's time for it to scan + * and reclaim some pages. */ - if (vm_pages_needed || (vm_paging_target() > -2048)) + if (vm_paging_need()) return (1); #if 0 _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
Author: avg Date: Fri Sep 17 07:34:50 2010 New Revision: 212783 URL: http://svn.freebsd.org/changeset/base/212783 Log: zfs arc_reclaim_needed: fix typo in mismerge in r212780 PR: kern/146410, kern/138790 MFC after: 3 weeks X-MFC with: r212780 Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c ============================================================================== --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c Fri Sep 17 07:20:20 2010 (r212782) +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c Fri Sep 17 07:34:50 2010 (r212783) @@ -2160,7 +2160,7 @@ arc_reclaim_needed(void) * Cooperate with pagedaemon when it's time for it to scan * and reclaim some pages. */ - if (vm_paging_need()) + if (vm_paging_needed()) return (1); #if 0 _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
Hi is there any progress on this? Am using 8.2-RC3 and FreeBSD has the exact same problem many months later. I was reading from UFS backups and my ufs cache using over 7 gig of ram in a 12gig machine rampant usage unchecked and zfs reducing its cache to make room. Really I agree with the original reporter that zfs tunables shouldnt need a reboot and more importantly ufs needs a sysctl knob to throttle its cache. I am considering setting a min cache size for zfs but I fear that ufs still wont hold back and I will find many gigs of memory swapped out.
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped
Keyword: patch or patch-ready – in lieu of summary line prefix: [patch] * bulk change for the keyword * summary lines may be edited manually (not in bulk). Keyword descriptions and search interface: <https://bugs.freebsd.org/bugzilla/describekeywords.cgi>