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

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: Scott Marlowe <smarlowe(at)g2switchworks(dot)com>
Cc: 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-20 14:45:04
Message-ID: 20060320144503.GR15742@pervasive.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

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.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Mikael Carneholm 2006-03-20 14:59:14 Migration study, step 1: bulk write performance optimization
Previous Message Qingqing Zhou 2006-03-20 12:03:14 Re: data doesnt get saved in the database / idle in transaction