Skip site navigation (1) Skip section navigation (2)

Re: Best OS & Configuration for Dual Xeon w/4GB &

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: Mark Kirkwood <markir(at)paradise(dot)net(dot)nz>
Cc: Scott Marlowe <smarlowe(at)g2switchworks(dot)com>,Kenji Morishige <kenjim(at)juniper(dot)net>,pgsql-performance(at)postgresql(dot)org
Subject: Re: Best OS & Configuration for Dual Xeon w/4GB &
Date: 2006-03-21 10:08:53
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
On Tue, Mar 21, 2006 at 03:51:35PM +1200, Mark Kirkwood wrote:
> Mark Kirkwood wrote:
> >
> >I think Freebsd 'Inactive' corresponds pretty closely to Linux's 
> >'Inactive Dirty'|'Inactive Laundered'|'Inactive Free'.
> >
> Hmmm - on second thoughts I think I've got that wrong :-(, since in 
> Linux all the file buffer pages appear in 'Cached' don't they...
> (I also notice that 'Inactive Laundered' does not seem to be mentioned 
> in vanilla - read non-Redhat - 2.6 kernels)
> So I think its more correct to say Freebsd 'Inactive' is similar to 
> Linux 'Inactive' + some|most of Linux 'Cached'.
> A good discussion of how the Freebsd vm works is here:
> In particular:
> "FreeBSD reserves a limited amount of KVM to hold mappings from struct 
> bufs, but it should be made clear that this KVM is used solely to hold 
> mappings and does not limit the ability to cache data."

It's worth noting that starting in either 2.4 or 2.6, linux pretty much
adopted the FreeBSD VM system (or so I've been told).
Jim C. Nasby, Sr. Engineering Consultant      jnasby(at)pervasive(dot)com
Pervasive Software    work: 512-231-6117
vcard:       cell: 512-569-9461

In response to

pgsql-performance by date

Next:From: Guillaume CottenceauDate: 2006-03-21 10:13:06
Subject: Re: planner with index scan cost way off actual cost, advices to tweak cost constants?
Previous:From: Jim C. NasbyDate: 2006-03-21 10:05:18
Subject: Re: data doesnt get saved in the database / idle in transaction

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group