Re: Postgresql 8.2.4 on linux-sparc problem

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Zelinskiy Alexander <alexander(dot)zelinskiy(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Postgresql 8.2.4 on linux-sparc problem
Date: 2008-01-12 18:53:20
Message-ID: 17054.1200164000@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Zelinskiy Alexander <alexander(dot)zelinskiy(at)gmail(dot)com> writes:
> I understand that this description can't give you enough information
> to give an advice what to do. But I don't know what to collect from OS/
> PG when it will happen again. Could you give me an advice what should
> I do when next time one of process will use all CPU time?

Before you get into that, try reducing these parameters:

> maintenance_work_mem = 1572864
> work_mem = 1048576

They are way too high, especially the second one. But if that doesn't
help:

> I guess that I can collect stack from this process at that time by
> using GDB or something like it. But I have no experience how exactly
> to do it.

Yup, that's the thing to do when you don't know what's happening.
The procedure is:

Determine PID of the troublesome backend (use ps or whatever).

As root or the postgres user, do

$ gdb /path/to/postgres-executable PID
... introductory noise, but the list of libraries can be useful ...
gdb> bt
... useful info here ...
gdb> quit
OK to detach? y
$

Necessary advance preparation: be sure gdb is installed and you have a
debug-enabled postgres (install debuginfo RPM if needed). I'd suggest
practicing and making sure that the backtrace shows routine names and
parameter values. As an example, a backtrace I was just looking at
looked in part like this:

#0 0x000000310202e174 in xmlCleanupCharEncodingHandlers ()
from /usr/lib64/libxml2.so.2
#1 0x0000003102036725 in xmlCleanupParser () from /usr/lib64/libxml2.so.2
#2 0x0000000000660e39 in xpath (fcinfo=<value optimized out>) at xml.c:3452
#3 0x000000000053601e in ExecMakeFunctionResult (fcache=0xb32f60,
econtext=0xb32e68, isNull=0xb33ed8 "", isDone=0xb33f90) at execQual.c:1351
#4 0x00000000005343c6 in ExecProject (projInfo=<value optimized out>,
isDone=0x0) at execQual.c:4601
#5 0x000000000053f5a5 in ExecAgg (node=0xb32b58) at nodeAgg.c:989
#6 0x0000000000533eaa in ExecProcNode (node=0xb32b58) at execProcnode.c:394

I do not have debuginfo installed for libxml2, thus the first two lines
provide very little information. The rest look more like what a
developer would like to see.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tomasz Myrta 2008-01-12 19:01:11 Re: know the schema name in a trigger
Previous Message Zelinskiy Alexander 2008-01-12 18:36:35 Postgresql 8.2.4 on linux-sparc problem