Date: Tue, 21 Sep 2010 14:53:26 +0100 From: "Steven Hartland" <killing@multiplay.co.uk> To: "Andriy Gapon" <avg@freebsd.org> Cc: freebsd-fs@freebsd.org Subject: Re: zfs very poor performance compared to ufs due to lack of cache? Message-ID: <EAA0054303614AB2A8CB8863BD54F68C@multiplay.co.uk> References: <5DB6E7C798E44D33A05673F4B773405E@multiplay.co.uk><4C874F00.3050605@freebsd.org><A6D7E134B24F42E395C30A375A6B50AF@multiplay.co.uk><4C8D087B.5040404@freebsd.org><03537796FAB54E02959E2D64FC83004F@multiplay.co.uk><4C8D280F.3040803@freebsd.org><3FBF66BF11AA4CBBA6124CA435A4A31B@multiplay.co.uk><4C8E4212.30000@freebsd.org> <B98EBECBD399417CA5390C20627384B1@multiplay.co.uk> <D79F15FEB5794315BD8668E40B414BF0@multiplay.co.uk> <4C90B4C8.90203@freebsd.org> <6DFACB27CA8A4A22898BC81E55C4FD36@multiplay.co.uk> <4C90D3A1.7030008@freebsd.org> <0B1A90A08DFE4ADA9540F9F3846FDF38@multiplay.co.uk> <4C90EDB8.3040709@freebsd.org> <3F29E8CED7B24805B2D93F62A4EC9559@multiplay.co.uk> <4C9126FB.2020707@freebsd.org> <1E0B9C1145784776A773B99FC1139CD5@multiplay.co.uk> <4C987F90.6000006@freebsd.org> <4C98803F.7000901@freebsd.org> <879BF5981D1B4C7290BDF18286BA1EEC@multiplay.co.uk> <4C989201.2 0506@freebsd.org> <A77828512281413B8B38EF02732D081C@multiplay.co.uk> <4C98A2BA.1080004@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
----- Original Message -----
From: "Andriy Gapon" <avg@freebsd.org>
>> From my tests it seems that to serve a file to a client using sendfile without
>> having to
>> read it from disk you need said file in ARC. See sendfile on and primarycache set to
>> metadata results.
>
> Yeah, I am puzzled by that.
> But, OTOH, I don't know that feature of ZFS well enough to say what additional
> pessimizations may have happened.
Anyone else care to comment on this?
>> So to use your caching analogy it seems that sendfile cant use the L1 cache unless
>> its also present in L2 for whatever reason.
>
> It's possible that this is how it works for you because of some bug.
> But I don't see anything in the code that would lead to that behavior _after_ the
> change that was committed in r212650. Change in r212782 might be useful too.
>
> In VM theory the data should be just taken from "L1" aka "Inactive" aka page cache.
That's what I thought you where saying. Is there a test you would suggest to confirm
either way more accurately?
What springs to mind is setting primarycache to metadata and requesting a large
single file multiple times and see if disk access is zero on the repeat requests.
If this turns out to be the case does anyone have an idea where the issue would be?
Regards
Steve
================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.
In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to postmaster@multiplay.co.uk.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EAA0054303614AB2A8CB8863BD54F68C>