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

Re: Vacuums on large busy databases

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Francisco Reyes <lists(at)stringsutils(dot)com>
Cc: Michael Stone <mstone+postgres(at)mathom(dot)us>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Vacuums on large busy databases
Date: 2006-09-15 00:52:02
Message-ID: 1158281522.29889.200.camel@dogma.v10.wvs (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
On Thu, 2006-09-14 at 20:04 -0400, Francisco Reyes wrote:
> Michael Stone writes:
> > On Thu, Sep 14, 2006 at 04:30:46PM -0400, Francisco Reyes wrote:
> >>Right now adding up from ps the memory I have about 2GB.
> > 
> > That's not how you find out how much memory you have. Try "free" or 
> > somesuch.
> Wasn't trying to get an accurate value, just a ballpark figure.
> When you say "free" are you refering to the free value from top? or some 
> program called free?

Any long-running system will have very little "free" memory. Free memory
is wasted memory, so the OS finds some use for it.

The VM subsystem of an OS uses many tricks, including the sharing of
memory among processes and the disk buffer cache (which is shared also).
It's hard to put a number on the memory demands of a given process, and
it's also hard to put a number on the ability of a system to accommodate
a new process with new memory demands.

You have 8GB total, which sounds like plenty to me. Keep in mind that if
you have the shared_memory all allocated on physical memory (i.e.
"kern.ipc.shm_use_phys: 1" on FreeBSD), then that amount of physical
memory will never be available to processes other than postgres. At 2GB,
that still leaves 6GB for the other process, so you should be fine.

	Jeff Davis

In response to


pgsql-performance by date

Next:From: Jeff DavisDate: 2006-09-15 00:59:26
Subject: Re: Vacuums on large busy databases
Previous:From: Jeff DavisDate: 2006-09-15 00:35:02
Subject: Re: Vacuums on large busy databases

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