From owner-freebsd-fs@FreeBSD.ORG Tue Sep 21 10:55:18 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 6944F1065673; Tue, 21 Sep 2010 10:55:18 +0000 (UTC) (envelope-from prvs=1880be0987=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id C85BF8FC14; Tue, 21 Sep 2010 10:55:17 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Tue, 21 Sep 2010 11:55:12 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Tue, 21 Sep 2010 11:55:12 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v10.0.4) with ESMTP id md50011281684.msg; Tue, 21 Sep 2010 11:55:11 +0100 X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1880be0987=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <879BF5981D1B4C7290BDF18286BA1EEC@multiplay.co.uk> From: "Steven Hartland" To: "Andriy Gapon" References: <5DB6E7C798E44D33A05673F4B773405E@multiplay.co.uk><4C85E91E.1010602@icyb.net.ua><4C873914.40404@freebsd.org><20100908084855.GF2465@deviant.kiev.zoral.com.ua><4C874F00.3050605@freebsd.org><4C8D087B.5040404@freebsd.org><03537796FAB54E02959E2D64FC83004F@multiplay.co.uk><4C8D280F.3040803@freebsd.org><3FBF66BF11AA4CBBA6124CA435A4A31B@multiplay.co.uk><4C8E4212.30000@freebsd.org> <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> Date: Tue, 21 Sep 2010 11:55:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Cc: freebsd-fs@freebsd.org 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: Tue, 21 Sep 2010 10:55:18 -0000 ----- Original Message ----- From: "Andriy Gapon" To: "Steven Hartland" Cc: 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.