Date: Tue, 21 Sep 2010 11:55:12 +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: <879BF5981D1B4C7290BDF18286BA1EEC@multiplay.co.uk> References: <5DB6E7C798E44D33A05673F4B773405E@multiplay.co.uk><AANLkTikNhsj5myhQCoPaNytUbpHtox1vg9AZm1N-OcMO@mail.gmail.com><4C85E91E.1010602@icyb.net.ua><4C873914.40404@freebsd.org><20100908084855.GF2465@deviant.kiev.zoral.com.ua><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>
next in thread | previous in thread | raw e-mail | index | archive | help
----- Original Message -----
From: "Andriy Gapon" <avg@freebsd.org>
To: "Steven Hartland" <killing@multiplay.co.uk>
Cc: <freebsd-fs@freebsd.org>
Sent: Tuesday, September 21, 2010 10:51 AM
Subject: Re: zfs very poor performance compared to ufs due to lack of cache?
> on 21/09/2010 12:49 Andriy Gapon said the following:
>> on 21/09/2010 12:27 Steven Hartland said the following:
>>> forces into Inact and ARC never seems to push back to balance this out :(
>>
>> Just a general note here.
>> ARC is not designed to "push back". It's designed to give up memory under
>> pressure, it's designed to expand into free space, it's not designed to create
>> the pressure.
>> Incorrect language produces incorrect perception resulting in incorrect
>> expectations.
It was my understanding that ARC when looking for available memory took Inactive
pages into account?
> I guess what I wanted to say is - why do you want ARC to grow more in this case?
> When you know that the data that sendfile uses is in those Inactive pages.
Well my understanding thus far, correct me if this is wrong, is that unless the data
in the memory populated by the use of sendfile "matches" those in ARC, having it
occupy that memory is pointless as it will never get used?
If this is the case all you will see is a cycling of memory use for different files and the
overall result will be that only ever 1.5G of files are actually cached, everything else
must still be read from disk "and" copied in memory before being sent?
What I would expect is the natural balance to be achieved, with Inactive pages and
ARC having an pretty even split. So on this machine with 7G say 500M possibly 1G
general overhead at a real push it would result in 3G Inactive pages from sendfile
matching the 3G of ARC?
ATM the only way to achieve this seems to be to manually tune min arc setting to this
level?
Sorry this is all questions, as I really don't have a clear picture of how this all works :(
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?879BF5981D1B4C7290BDF18286BA1EEC>