Обсуждение: Postgre "idle" process using 100% CPU
Hi, i am using postgresql version 8.0.1 on Gentoo Linux and from time to time a postgres process that is marked as idle - "postgres: user db IP(34079) idle" - starts using 100% CPU. There is nothing in the logs, so i don't have a clue what could be the problem. Regards, Jernej Kos. -- Jernej Kos <kostko@jweb-network.net> JWeb-Network
Jernej Kos <kostko@jweb-network.net> writes:
> i am using postgresql version 8.0.1 on Gentoo Linux and from time to time a
> postgres process that is marked as idle - "postgres: user db IP(34079) idle"
> - starts using 100% CPU. There is nothing in the logs, so i don't have a clue
> what could be the problem.
For a long time? I'd expect it to go busy on receiving a command
somewhat before changing the PS status, because command parsing
happens first (else it can't know what to set the status to ...).
If you are in the habit of sending enormously complex SQL commands
then maybe this state would last long enough to notice.
If you don't think that's it, maybe you could attach to the busy
backend with gdb and get a stack trace to find out what it's doing?
regards, tom lane
Well there should be no complex queries executed (there are some huge tables, but the queries aren't huge or specially complicated). I tried attaching to the process via gdb and the process is executing method: HeapTupleSatisfiesSnapshot() The backtrace appears to be useless (too many ??s). Is that of any help ? Regards, Jernej Kos. On Thursday 09 of June 2005 17:19, you wrote: > Jernej Kos <kostko@jweb-network.net> writes: > > i am using postgresql version 8.0.1 on Gentoo Linux and from time to time > > a postgres process that is marked as idle - "postgres: user db IP(34079) > > idle" - starts using 100% CPU. There is nothing in the logs, so i don't > > have a clue what could be the problem. > > For a long time? I'd expect it to go busy on receiving a command > somewhat before changing the PS status, because command parsing > happens first (else it can't know what to set the status to ...). > If you are in the habit of sending enormously complex SQL commands > then maybe this state would last long enough to notice. > > If you don't think that's it, maybe you could attach to the busy > backend with gdb and get a stack trace to find out what it's doing? > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org -- Jernej Kos <kostko@jweb-network.net> JWeb-Network
Jernej Kos <kostko@jweb-network.net> writes:
> Well there should be no complex queries executed (there are some huge tables,
> but the queries aren't huge or specially complicated). I tried attaching to
> the process via gdb and the process is executing method:
> HeapTupleSatisfiesSnapshot()
> The backtrace appears to be useless (too many ??s). Is that of any help ?
It's really hard to see how it could get to HeapTupleSatisfiesSnapshot()
without being inside a query --- too bad you can't get a more usable
backtrace. Is it worth recompiling with --enable-debug to investigate
this?
regards, tom lane
Well I can't get any better backtraces (even with --enable-debug). The strange thing is that this just happens once in a while and the process doesn't stop until it is killed (or postgre is restarted). Any suggestions ? Regards, Jernej Kos. On Sunday 12 of June 2005 18:01, you wrote: > Jernej Kos <kostko@jweb-network.net> writes: > > Well there should be no complex queries executed (there are some huge > > tables, but the queries aren't huge or specially complicated). I tried > > attaching to the process via gdb and the process is executing method: > > > > HeapTupleSatisfiesSnapshot() > > > > The backtrace appears to be useless (too many ??s). Is that of any help ? > > It's really hard to see how it could get to HeapTupleSatisfiesSnapshot() > without being inside a query --- too bad you can't get a more usable > backtrace. Is it worth recompiling with --enable-debug to investigate > this? > > regards, tom lane -- Jernej Kos <kostko@jweb-network.net> JWeb-Network