From owner-freebsd-questions@FreeBSD.ORG Tue Jan 13 07:05:22 2015 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C0437DC8 for ; Tue, 13 Jan 2015 07:05:22 +0000 (UTC) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9999CFE5 for ; Tue, 13 Jan 2015 07:05:22 +0000 (UTC) Received: by mail-pd0-f179.google.com with SMTP id fp1so1787909pdb.10 for ; Mon, 12 Jan 2015 23:05:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Pd3lDyKj6K6WQx9IutRxsH6N38EO2xi+2060mc67Kxo=; b=DdXWlpYosmsJm1rD3C3Y8qZjV9tJtf+SicF2EdC936VMHr0+57KCafl4lAYh+heVmd FF6gcsqP7W4oSQ4dEGk9XywR/cnZk5G3Y/P+v8lVCfxg1+SqXu7q3V1bsglxbsjWPNBL FFvgwFldgNXm/oVipua8tfnC2t2g23HRIBu5TSTrwQ+0HjklruPCbRLiPJG0/LpN3mum FSrNlG1yg22/0J/qB3ZauEGbC6MZbBd+0SC6vJrtGy2VpbALl+22FQxeOX+n4v9bdRke phxs0V6dlmXekOizyQjJ0QILZ0biX7H13ZQWjlRLqa1cUIX3/3mg4c9TuD8IkDMux8Ah HJ2w== X-Received: by 10.68.234.200 with SMTP id ug8mr49206222pbc.133.1421132722098; Mon, 12 Jan 2015 23:05:22 -0800 (PST) Received: from [192.168.1.2] (c-71-237-219-238.hsd1.or.comcast.net. [71.237.219.238]) by mx.google.com with ESMTPSA id n2sm16118341pdo.0.2015.01.12.23.05.20 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Jan 2015 23:05:20 -0800 (PST) Message-ID: <54B4C3AF.3050705@gmail.com> Date: Mon, 12 Jan 2015 23:05:19 -0800 From: Lacey Powers User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: freebsd-questions@freebsd.org Subject: Re: Calculating Dirty Memory References: <54B45465.7040501@gmail.com> <20150113014151.742c1aa1@gumby.homeunix.com> In-Reply-To: <20150113014151.742c1aa1@gumby.homeunix.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 07:05:22 -0000 On 01/12/2015 17:41, RW wrote: > On Mon, 12 Jan 2015 15:10:29 -0800 > Lacey Powers wrote: > >> Hello Everyone, >> >> I was working on trying to improve some database benchmarking tools >> for PostgreSQL, to work better on FreeBSD. >> >> One of the things that the tools do under Linux is >> read /proc/meminfo, and grab the value of the Dirty parameter, which >> is this: >> >> "Dirty ? The total amount of memory, in kilobytes, waiting to be >> written back to the disk." according to the CentOS documentation and >> other sources. > AFAIK the word "dirty" can refer to any page that isn't synchronized > with it's backing store, including swap-backed memory that may never be > written to disk. > >> Poking around the FreeBSD documentation, Google, and sysctls, I came >> to this calculation: >> >> (vm.stats.vm.v_page_size * vm.stats.vm.v_inactive_count) / 1024 = >> Inactive (Dirty) kB (page size in bytes *number of pages) / 1024 > > v_inactive_count includes dirty and clean pages. > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" Hello RW, Thank you for the reply. =) I based the choice of v_inactive_count off of these lines from my previously linked documentation: "The system must make a distinction between clean pages which can theoretically be freed up at any time, and dirty pages which must first be written to their backing store before being reusable. When a page candidate has been found it is moved to the inactive queue if it is dirty, or the cache queue if it is clean. A separate algorithm based on the dirty-to-clean page ratio determines when dirty pages in the inactive queue must be flushed to disk." However, considering your comment regarding v_inactive_count, several more reads through that document, and this later line "What this means is that FreeBSD will not try very hard to separate out dirty pages (inactive queue) from clean pages (cache queue) when the system is not being stressed, nor will it try to deactivate pages (active queue -> inactive queue) when the system is not being stressed, even if they are not being used." It seems that any of the vm stats exposed via sysctl are a poor metric for calculating memory waiting to be written to disk, due to the "lazy" paging. So much for an easy answer. =) Should I instead be looking at the filesystems in FreeBSD? Are there additional resources you could recommend? Again, thank you for your reply and assistance. =) Lacey