From: "Merlin Moncure" <mmonc...@gmail.com>
can we see all of your memory settings plus physical memory? the
solution is probably going to be reducing shared buffers an/or adding
physical memory.
Thank you for your response.
The amount of physical memory is 8GB, which is enough for the workload. I
asked the customer for the output of "SHOW ALL", but I haven't received it
yet. However, shared_buffers should be less than 1.6GB because, as I wrote
in the previous mail, top command showed 1.6GB in "VIRT" column before
executing somefunc() PL/pgSQL function.
The direct cause of "out of memory" is that the virtual memory became full.
32-bit Linux can allocate 3GB of user space in the virtual address space of
each process. somefunc() used 1.0GB, which led to 2.6GB of virtual memory.
After somefunc(), VACUUM tried to allocate 256MB of maintenance_work_mem.
That allocation failed because the virtual address space was almost full.
As you mentioned, decreasing shared_buffers will be one of the solutions.
However, we want to know why somefunc() uses so much memory. Therefore, the
following is the core question. Q2 and Q3 are supplementary ones. It is just
my guess that RelCache/SysCache may be the cause.
2011/9/28 MauMau <maumau...@gmail.com>:
Q1: When are the RelCache/SysCache entries removed from
CacheMemoryContext?
Are they removed only when the corresponding relations are deleted? If so,
"many tables and indexes" is not friendly for the current PostgreSQL?
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
