Date: Tue, 21 Mar 2006 14:57:37 +1200
From: Mark Kirkwood <markir@paradise.net.nz>
Subject: Re: Best OS & Configuration for Dual Xeon w/4GB &
In-reply-to: <1142871620.17883.4.camel@state.g2switchworks.com>
To: Scott Marlowe <smarlowe@g2switchworks.com>
Cc: "Jim C. Nasby" <jnasby@pervasive.com>,
	Kenji Morishige <kenjim@juniper.net>, pgsql-performance@postgresql.org
Message-id: <441F6BA1.20005@paradise.net.nz>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7bit
User-Agent: Mozilla Thunderbird 1.0.6 (X11/20051106)
References: <20060317221116.GA14661@juniper.net>
	<1142636433.1141.33.camel@state.g2switchworks.com>
	<20060320144503.GR15742@pervasive.com>
	<1142871620.17883.4.camel@state.g2switchworks.com>

Scott Marlowe wrote:
> On Mon, 2006-03-20 at 08:45, Jim C. Nasby wrote:
> 
>>On Fri, Mar 17, 2006 at 05:00:34PM -0600, Scott Marlowe wrote:
>>
>>>>last pid:  5788;  load averages:  0.32,  0.31,  0.28                                                     up 127+15:16:08 13:59:24
>>>>169 processes: 1 running, 168 sleeping
>>>>CPU states:  5.4% user,  0.0% nice,  9.9% system,  0.0% interrupt, 84.7% idle
>>>>Mem: 181M Active, 2632M Inact, 329M Wired, 179M Cache, 199M Buf, 81M Free
>>>>Swap: 4096M Total, 216K Used, 4096M Free
>>>>
>>>>  PID USERNAME      PRI NICE  SIZE    RES STATE  C   TIME   WCPU    CPU COMMAND
>>>>14501 pgsql           2   0   254M   242M select 2  76:26  1.95%  1.95% postgre
>>>> 5720 root           28   0  2164K  1360K CPU0   0   0:00  1.84%  0.88% top
>>>> 5785 pgsql           2   0   255M 29296K sbwait 0   0:00  3.00%  0.15% postgre
>>>> 5782 pgsql           2   0   255M 11900K sbwait 0   0:00  3.00%  0.15% postgre
>>>> 5772 pgsql           2   0   255M 11708K sbwait 2   0:00  1.54%  0.15% postgre
>>>
>>>That doesn't look good.  Is this machine freshly rebooted, or has it
>>>been running postgres for a while?  179M cache and 199M buffer with 2.6
>>>gig inactive is horrible for a machine running a 10gig databases.
>>
>>No, this is perfectly fine. Inactive memory in FreeBSD isn't the same as
>>Free. It's the same as 'active' memory except that it's pages that
>>haven't been accessed in X amount of time (between 100 and 200 ms, I
>>think). When free memory starts getting low, FBSD will start moving
>>pages from the inactive queue to the free queue (possibly resulting in
>>writes to disk along the way).
>>
>>IIRC, Cache is the directory cache, and Buf is disk buffers, which is
>>somewhat akin to shared_buffers in PostgreSQL.
> 
> 
> So, then, the inact is pretty much the same as kernel buffers in linux?
> 

I think Freebsd 'Inactive' corresponds pretty closely to Linux's 
'Inactive Dirty'|'Inactive Laundered'|'Inactive Free'.

 From what I can see, 'Buf' is a bit misleading e.g. read a 1G file 
randomly and you increase 'Inactive' by about 1G - 'Buf' might get to 
200M. However read the file again and you'll see zero i/o in vmstat or 
gstat. From reading the Freebsd architecture docs, I think 'Buf' 
consists of those pages from 'Inactive' or 'Active' that were last kvm 
mapped for read/write operations. However 'Buf' is restricted to a 
fairly small size (various sysctls), so really only provides a lower 
bound on the file buffer cache activity.

Sorry to not really answer your question Scott - how are Linux kernel 
buffers actually defined?

Cheers

Mark