Re: memory

From: "Guido Barosio" <gbarosio(at)gmail(dot)com>
To: "Tom Allison" <tallison(at)tacocat(dot)net>
Cc: "Richard Broersma Jr" <rabroersma(at)yahoo(dot)com>, pgsql-novice(at)postgresql(dot)org
Subject: Re: memory
Date: 2006-11-10 02:50:32
Message-ID: f7f6b4c70611091850m2c273261u8cdec4bbcdaf20fe@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-novice

There is a contrib module (not sure now if it is already a pgfoundry
project, tho) that will help you while trying to figure out the buffer
hits.

Best whishes,
g.-

On 11/9/06, Tom Allison <tallison(at)tacocat(dot)net> wrote:
> Richard Broersma Jr wrote:
> >> I've a relatively small machine (512MB) that I am setting up as a small area
> >> database server. And I was trying to get the memory balanced out for this
> >> machine. I don't plan on running anything other than postgresql and whatever
> >> might be required to operate sanely on the network.
> >> So I was changing my shared buffers and found I couldn't really get over 3500
> >> before SHMMAX started complaining.
> >> That being done, I'm running some jobs now on this server and have noticed that
> >> postgres uses only a few percentage points of the available memory according to top.
> >> So, I'm trying to understand why I don't have more memory being used up by these
> >> SQL jobs. I was assuming that running 100 SQL statements/second would suck up a
> >> lot of memory.
> >> Right now all it seems to burn in CPU cycles more than RAM.
> >> Maybe I don't understand much about how postgres will appear to operate...
> >> But is the memory limited by the shared_buffers * max_connections?
> >
> > Don't forget that if you database is significantly smaller than you memory, it could reside
> > entirely in Kernel memory cache. The shared_buffer is used (IIRC) to allocate memory specifically
> > for preforming complicated data transformations required by your issued SQL statement. The larger
> > larger the data set your transforming or the more complication your sql statements are,
> > performance can benefit from increased shared_buffers. However, I believe that this can reduce
> > the amount of memory available for caching the rest of your database in memory.
> >
> > But to verify what I've mentioned please see the following:
> >
> > http://www.varlena.com/varlena/GeneralBits/Tidbits/annotated_conf_e.html
> > http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html
> > http://www.postgresql.org/files/documentation/books/aw_pgsql/hw_performance/
> >
> > Regards,
> >
> > Richard Broersma Jr.
> >
>
> Lots to learn.
>
> I changed the shmmax to ~442MB and changed the shared_buffers from 3000 to 52000.
> The database is MUCH faster, less load on the cpu, but takes 50% of the RAM.
> I don't know how much of the data is cached per se -- but it's an improvement.
>
> Now I probably have to worry about using too much memory...
>
> Lots to learn.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>

--
Guido Barosio
-----------------------
http://www.globant.com
guido(dot)barosio(at)globant(dot)com

In response to

  • Re: memory at 2006-11-10 02:25:34 from Tom Allison

Browse pgsql-novice by date

  From Date Subject
Next Message Adam Ciazynski 2006-11-10 08:08:31 ECPG and multiple threads
Previous Message Richard Broersma Jr 2006-11-10 02:34:10 Re: memory