From owner-freebsd-fs@FreeBSD.ORG Mon Sep 6 10:54:22 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B28B10656AE for ; Mon, 6 Sep 2010 10:54:21 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 57A8D8FC16 for ; Mon, 6 Sep 2010 10:54:19 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA00410; Mon, 06 Sep 2010 13:54:16 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4C84C857.1070306@icyb.net.ua> Date: Mon, 06 Sep 2010 13:54:15 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100823 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Steven Hartland References: <5DB6E7C798E44D33A05673F4B773405E@multiplay.co.uk><4C825D65.3040004@DataIX.net> <7EA7AD058C0143B2BF2471CC121C1687@multiplay.co.uk> <1F64110BFBD5468B8B26879A9D8C94EF@multiplay.co.uk> <4C83A214.1080204@DataIX.net> <06B9D23F202D4DB88D69B7C4507986B7@multiplay.co.uk> <4C842905.2080602@DataIX.net> <330B5DB2215F43899ABAEC2CF71C2EE0@multiplay.co.uk> In-Reply-To: <330B5DB2215F43899ABAEC2CF71C2EE0@multiplay.co.uk> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, jhell Subject: Re: zfs very poor performance compared to ufs due to lack of cache? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2010 10:54:22 -0000 on 06/09/2010 02:57 Steven Hartland said the following: > Based on Jeremy's comments I'm updating the box the stable. Its building now > but will be the morning before I can reboot to activate changes as I need to > deactivate the stream instance and wait for all active connections to finish. > > That said the problem doesn't seem to be cache + free but more cache + free > + inactive with inactive being the large chunk, so not sure this change > would make any difference? > > How does ufs deal with this, does it take inactive into account? Seems a bit > silly for inactive pages to prevent reuse for extended periods when the > memory could be better used as cache. Inactive pages are also a cache, just a different kind. > As an experiment I compiled a little app which malloced a large block of > memory, 1.3G in this case and then freed it. This does indeed pull the memory > out of inactive and back into the free pool where zfs is which happy to > re-expand arc and once again cache large files. Seems a bit extreme to have to > do this though. > > Will see what happens with stable tomorrow though :) Don't forget the change that I suggested (from Artem's link). You may want to read the whole post too, I tried to explain what's going on with inactive and what the change tries to accomplish. -- Andriy Gapon