problem with memory
Hello
one czech PostgreSQL user reports problem with memory - probable memleak?
Is possible to diagnose some from log?
Postgres ver. 8.3.7 .
Server 8G RAM, 32b Debian Etch.
Configuration:
shared_buffers = 324000 # min 16 or max_connections*2, 8KB each
temp_buffers = 16000 # min 100, 8KB each
work_mem = 8126 # min 64, size in KB
maintenance_work_mem = 16384 # min 1024, size in KB
max_stack_depth = 7680 # min 100, size in KB
max_fsm_pages = 200000 # min max_fsm_relations*16, 6 bytes
max_fsm_relations = 12000 # min 100, ~70 bytes each
effective_cache_size = 300000 # typically 8KB each
http://jyxo.cz/misc/sql.error.txt
Thank you
Pavel Stehule
Pavel Stehule <pavel.stehule@gmail.com> writes:
one czech PostgreSQL user reports problem with memory - probable memleak?
Is possible to diagnose some from log?
If he's getting an actual "out of memory" error, let's see the memory
context map that gets dumped to the server log (or more specifically,
to stderr).
Server 8G RAM, 32b Debian Etch.
shared_buffers = 324000 # min 16 or max_connections*2, 8KB each
Although you may have told us enough right here. 2.5GB of shared
buffers in a 4GB address space (with probably only 3GB available to the
application) isn't a very sane choice. Back that off or run 64-bit.
regards, tom lane
The link was to the memory context dump. The only suspicious context I
spotted was 300mb in MessageContext. What is lc_messages and lc_ctype
set to on this machine? Were the latest round of infinite recursion in
the character conversion routines in 8.3.7?
--
Greg
On 26 May 2009, at 17:00, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Show quoted text
Pavel Stehule <pavel.stehule@gmail.com> writes:
one czech PostgreSQL user reports problem with memory - probable
memleak?
Is possible to diagnose some from log?If he's getting an actual "out of memory" error, let's see the memory
context map that gets dumped to the server log (or more specifically,
to stderr).Server 8G RAM, 32b Debian Etch.
shared_buffers = 324000 # min 16 or max_connections*2, 8KB
eachAlthough you may have told us enough right here. 2.5GB of shared
buffers in a 4GB address space (with probably only 3GB available to
the
application) isn't a very sane choice. Back that off or run 64-bit.regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Greg Stark <greg.stark@enterprisedb.com> writes:
Were the latest round of infinite recursion in
the character conversion routines in 8.3.7?
Yes, and in any case the typical symptom of that problem was a SIGSEGV
(due to stack overrun) not an out-of-memory complaint.
regards, tom lane