Re: What's using all my RAM?

Thanks for this.
I couldn't get vacuum to run on even the smallest table, so I
re-investigated RAM. We changed our SHMMAX to 1.3gb on this 4gb RAM system
in line with the systems we have already converted to Postgres 8.1.4, but v8
handles RAM differently (vacuum_mem replaced with maintenance_work_mem), and
SHMMAX usage has changed (v8 uses less SHMMAX - about 300mb - where v7 grabs
all 1.3gb and holds it), so when vacuum tried to run and get 1gb of RAM on
v7, it failed. We reduced vacuum_mem to 8192kb on v7 and the vacuum runs
happily with SHMMAX at 1.3gb.

On 8/3/06, Scott Marlowe <smarlowe(at)g2switchworks(dot)com> wrote:
>
> On Tue, 2006-08-01 at 23:09, adey wrote:
> > Please could someone tell me how to discover what is using all of my
> > RAM?
> > I am trying to run a vacuum against Postgres, but it fails immediately
> > with:-
> >
> > "ERROR: out of memory
> > DETAIL: Failed on request of size 1073741820."
> >
> > TOP shows the following:-
> > Mem: 4077544k total, 3897868k used, 179676k free, 146960k
> > buffers
> > Swap: 2000084k total, 440k used, 1999644k free, 3352892k
> > cached
> > None of the listed processes appear to be using more than 1 or 2% MEM.
>
> nothing is using your ram in the traditional sense.You're kernel is
> caching files in the space that's not currently being used by
> applications. note that you show 3897868k used, and 3352892k cached.
> So, the actual memory being use by applications is the in use minus the
> cached, or about 544,000k. The rest is actually available, and the
> kernel will gladly give it back if a program needs it.
>
> You actual problem here is that your machine is trying to allocate
> approx 1 Gig at once. Large allocations tend to point towards some kind
> of data corruption in your database, but not always.
>
> Try a vacuuming each table one at a time to see which one is causing
> this error (if it's not already in the error message and got edited
> away.) See if a select of all rows on that table gets the same error
> message.
>
> > Postgres v7.4.2 (upgrade underway)
>
> If you can get a clean backup, look into at least 8.0. There were huge
> improvements from 7.4 to 8.0. 8.1 is even more impressive. (says the DBA
> who's still running 7.4.13 on all his boxes... :)
>