Skip site navigation (1) Skip section navigation (2)

Re: rebellious pg stats collector (reopened case)

From: Laszlo Nagy <gandalf(at)shopzeus(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-admin(at)postgresql(dot)org
Subject: Re: rebellious pg stats collector (reopened case)
Date: 2008-12-29 08:06:51
Message-ID: 4958851B.8060500@shopzeus.com (view raw or flat)
Thread:
Lists: pgsql-adminpgsql-performance
Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
>   
>> Tom Lane wrote:
>>     
>>> I wonder whether your tracing tool is affecting the result of
>>> getppid().  Most people would consider that a bug in the tracing tool.
>>>       
>
>   
I wrote to an official the FreeBSD list about this getppid() problem but 
got no answer other than that "this behaviour is documented". :-(

The problem is still there:


  PID USERNAME       THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU 
COMMAND
11205 pgsql            1 104    0 22400K  7112K CPU5   5 159.7H 99.02% 
postgres


100% CPU since 159 hours! What can I do? Instead of tracing system 
calls, is there a way to start the stats collector in debug mode? Or 
maybe is it possible to change the source code, and disable the "is 
postmaster alive" check for testing?

Thanks


In response to

Responses

pgsql-performance by date

Next:From: Laszlo NagyDate: 2008-12-29 09:43:42
Subject: Re: Slow table update
Previous:From: Ted AllenDate: 2008-12-29 03:11:47
Subject: Re: Troubles dumping a very large table.

pgsql-admin by date

Next:From: Tom LaneDate: 2008-12-29 15:26:33
Subject: Re: rebellious pg stats collector (reopened case)
Previous:From: Raj MathurDate: 2008-12-27 02:36:55
Subject: [DOCUMENT] Migrating Oracle to PostgresSQL

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group