Re: What's using all my RAM?

Поиск
Список
Период
Сортировка
От adey
Тема Re: What's using all my RAM?
Дата
Msg-id 1c66bda80608021623y19a335b4y7b1ec6401eeb87fb@mail.gmail.com
обсуждение исходный текст
Ответ на Re: What's using all my RAM?  (Scott Marlowe <smarlowe@g2switchworks.com>)
Список pgsql-admin
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@g2switchworks.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... :)

В списке pgsql-admin по дате отправления:

Предыдущее
От: "Aaron Bono"
Дата:
Сообщение: Re: Controlling CPU Usage in PostgreSQL
Следующее
От: adey
Дата:
Сообщение: Re: how to increase performance of Postgre