Re: "Out of memory" errors.. - Mailing list pgsql-general

From Lim Berger
Subject Re: "Out of memory" errors..
Date
Msg-id 69d2538f0708130812icb723a7l7fde0fc8abd5e13a@mail.gmail.com
Whole thread Raw
In response to Re: "Out of memory" errors..  (Gregory Stark <stark@enterprisedb.com>)
List pgsql-general
My responses below yours. Thanks so much for bearing with me..



On 8/13/07, Gregory Stark <stark@enterprisedb.com> wrote:
> "Lim Berger" <straightfwd007@gmail.com> writes:
>
> > On 8/13/07, Gregory Stark <stark@enterprisedb.com> wrote:
> >> "Lim Berger" <straightfwd007@gmail.com> writes:
> >>
> >> > Hi
> >> >
> >> > I am getting the following error while running queries such as "vacuum
> >> > analyze TABLE", even on small tables with a piddly 35,000 rows!
> >> >
> >> > The error message:
> >> > --
> >> > ERROR:  out of memory
> >> > DETAIL:  Failed on request of size 67108860.
> >> > --
> >> >
> >> > My postgresql.conf is below. I am on a Dual Core server with 4GB or
> >> > RAM, which runs MySQL as well (key_buffer for which is at around
> >> > 800M).
> >>
> >> What version of Postgres is this?
> >
> > =# select version();
> >                                                 version
> > ----------------------------------------
> >  PostgreSQL 8.2.3 on i686-redhat-linux-gnu, compiled by GCC gcc (GCC)
> > 3.4.6 20060404 (Red Hat 3.4.6-3)
> > (1 row)
>
> Hm, this is quite odd.
>



> Could you give more information? You're getting this
> on lots of different tables?


Yes, all of them. The example I gave is the smallest table with about
35,000 rows.

Btw, before anything else, the tweaking comments here --
http://www.powerpostgresql.com/PerfList/  ..suggest that for
autovacuum I need to recompile and have settings like "-D -v 400 -V
0.4 -a 100 -A 0.3".

Where do I do this? I don't have any such setting in my
postgresql.conf! How should I find out if autovacuum is set up and
functional, and at what points it enters and vacuums up?


> Could you give more examples? And do you get it on anything
> other than vacuum analyze?


More examples of "vacuum analyze" on other tables? Every table gives
the same error. ANALYZE alone works ok. SELECTing works ok. Multiple
UPDATEing in a transaction block works ok. So does INSERT. What other
examples could I furnish? Please help me help you help me :)


> What does the schema look like?
>


You mean the entire tables definition? Below it is. It's a simple
schema, because I am sharing the workload between MySQL and PGSQL for
now, slowly switching to PGSQL.


                       List of relations
 Schema |          Name           |   Type   |      Owner
--------+-------------------------+----------+-----------------
 public | program                 | table    | MYUSERID
 public | program_id_seq          | sequence | MYUSERID
 public | program_subscribers     | table    | MYUSERID
 public | mini                    | table    | MYUSERID
 public | users                   | table    | MYUSERID
(5 rows)


PROGRAM table has 35,000 rows
PROGRAM_SUBSCRIBERS has 10,000
MINI has about 3 million
USERS has about 200.

On this small DB, I am not sure why there is memory outage. Just one
thing -- the "MINI" table has **huge** concurrent usage, about 10,000
accesses per minute, and it has only three columns so it is a bit of a
caching table.

It does have an index though, that is used in our queries very simply
and effeciently, because this concurrent use is all with an "=" query
on the indexed column. Very small, fast queries.

In MYSQL, this used to be very fast due to their "query cache", but
there is no equivalent in PGSQL inside the DB, not outside of the
usual filesystem anyway, so I am not sure if PGSQL is holding up to
the concurrent usage.

To test this ignorant hypothesis of whether PGSQL was buckling under
huge concurrent pressure, I restarted the postgresql process, and the
memory problem is still there, so I doubt the memory outage is caused
by huge concurrent access.

PGSQL (seems to) return the results very fast as well.



> Do you have any hash indexes? (there was a bug fixed
> in 8.2.4 with them)


Nope. Very simple tables actually, all with one BTREE index each. The
complex stuff is still in MySQL and totally separate from this. There
are five tables in MYSQL with compound indexes on 2 to 5 columns. But
that is besides the point for now.


> Do you have anything else unusual like tsearch2 or
> custom C modules loaded?


Not that I know of, unless they are included by default. How can I
check? If they are not smooshed in, then no, I don't have them
installed.


> Has anything unusual happened to this machine such as a
> server crash or power failure?


Hmm, not really. But I did reboot it last week when it buckled under a
MYSQL REPAIR TABLE issue. I wonder how that could be related to PGSQL
though? Same machine and all? It wasn't a very dramatic crash or
anything.



> Is anything else failing? Can you run a good memory tester like
> memtest86? Could you check your dmesg log to see if there are any system
> problems?



Wow, this is all a bit technical for me. I went to the memtest86 site,
and downloaded their binary. Now I will try to do the untarring and
make/makeinstall stuff, but their site is very sparse on info.

But here is my memory check info from the server:

---
MemTotal:      4148844 kB
MemFree:        793052 kB
Buffers:        130280 kB
Cached:        2333716 kB
SwapCached:       7304 kB
Active:        2551448 kB
Inactive:       711836 kB
HighTotal:     3276160 kB
HighFree:       237184 kB
LowTotal:       872684 kB
LowFree:        555868 kB
SwapTotal:     2096440 kB
SwapFree:      2084700 kB
Dirty:            1996 kB
Writeback:           0 kB
Mapped:         836816 kB
Slab:            65140 kB
CommitLimit:   4170860 kB
Committed_AS:  2531972 kB
PageTables:       9284 kB
VmallocTotal:   106488 kB
VmallocUsed:      3284 kB
VmallocChunk:   102504 kB
HugePages_Total:     0
HugePages_Free:      0
Hugepagesize:     2048 kB
---


The dmesg output shows me this blabber, which I have no idea where to
begin decoding. It'd be great if you could point me in the right
direction?


-----BEGIN----
Mem-info:
DMA per-cpu:
cpu 0 hot: low 2, high 6, batch 1
cpu 0 cold: low 0, high 2, batch 1
cpu 1 hot: low 2, high 6, batch 1
cpu 1 cold: low 0, high 2, batch 1
cpu 2 hot: low 2, high 6, batch 1
cpu 2 cold: low 0, high 2, batch 1
cpu 3 hot: low 2, high 6, batch 1
cpu 3 cold: low 0, high 2, batch 1

Normal per-cpu:
cpu 0 hot: low 32, high 96, batch 16
cpu 0 cold: low 0, high 32, batch 16
cpu 1 hot: low 32, high 96, batch 16
cpu 1 cold: low 0, high 32, batch 16
cpu 2 hot: low 32, high 96, batch 16
cpu 2 cold: low 0, high 32, batch 16
cpu 3 hot: low 32, high 96, batch 16
cpu 3 cold: low 0, high 32, batch 16

HighMem per-cpu:
cpu 0 hot: low 32, high 96, batch 16
cpu 0 cold: low 0, high 32, batch 16
cpu 1 hot: low 32, high 96, batch 16
cpu 1 cold: low 0, high 32, batch 16
cpu 2 hot: low 32, high 96, batch 16
cpu 2 cold: low 0, high 32, batch 16
cpu 3 hot: low 32, high 96, batch 16
cpu 3 cold: low 0, high 32, batch 16

Free pages:      417404kB (404864kB HighMem)
Active:458596 inactive:451436 dirty:145735 writeback:48813 unstable:0
free:104351 slab:15369 mapped:411925 pagetables:2938
DMA free:12540kB min:16kB low:32kB high:48kB active:0kB inactive:0kB
present:16384kB pages_scanned:297 all_unreclaimable? yes
protections[]: 0 0 0
Normal free:0kB min:928kB low:1856kB high:2784kB active:271116kB
inactive:511380kB present:901120kB pages_scanned:1749
all_unreclaimable? no
protections[]: 0 0 0
HighMem free:404864kB min:512kB low:1024kB high:1536kB
active:1563284kB inactive:1293200kB present:4063232kB pages_scanned:0
all_unreclaimable? no
protections[]: 0 0 0
DMA: 1*4kB 3*8kB 4*16kB 3*32kB 3*64kB 1*128kB 1*256kB 1*512kB 1*1024kB
1*2048kB 2*4096kB = 12540kB
Normal: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB
0*1024kB 0*2048kB 0*4096kB = 0kB
HighMem: 14382*4kB 24921*8kB 5608*16kB 1802*32kB 1*64kB 0*128kB
0*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 404864kB
Swap cache: add 190137, delete 125938, find 44796/57030, race 0+17
0 bounce buffer pages
Free swap:       1817480kB
1245184 pages of RAM
819040 pages of HIGHMEM
207973 reserved pages
469280 pages shared
65337 pages swap cached
-----END-----



Thanks for bearing with me!
LB

pgsql-general by date:

Previous
From: Erik Jones
Date:
Subject: Re: non superuser creating flat files
Next
From: "Lim Berger"
Date:
Subject: Re: "Out of memory" errors..