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.

Postgres v7.4.2 (upgrade underway)

adey <adey11@gmail.com> writes:
> 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."

I'd bet lunch that this is a corrupt-data problem, not an out-of-memory
problem --- specifically, a bad value in a field length word. See the
archives for many prior examples.

> Postgres v7.4.2 (upgrade underway)

Yipes :-(

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

On Wed, Aug 02, 2006 at 12:37:47AM -0400, Tom Lane wrote:
> adey <adey11@gmail.com> writes:
> > 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."
>
> I'd bet lunch that this is a corrupt-data problem, not an out-of-memory
> problem --- specifically, a bad value in a field length word. See the
> archives for many prior examples.

1073741820 = 3ffffffc = 00111111111111111111111111111100

That doesn't explain anything but it's an interesting-looking number.

--
Michael Fuhr

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

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...

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

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...
>

On Aug 2, 2006, at 11:34 AM, Scott Marlowe wrote:
>> 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...

Most importantly, you're running the most recent version of 7.4. The
OP needs to run (not walk) to 7.4.13.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461



---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly