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

Re: Strange performance degradation

From: Lorenzo Allegrucci <lorenzo(dot)allegrucci(at)forinicom(dot)it>
Cc: pgsql-performance(at)postgresql(dot)org, pgsql-general(at)postgresql(dot)org
Subject: Re: Strange performance degradation
Date: 2009-11-23 20:46:41
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-generalpgsql-performance
Tom Lane wrote:
> Lorenzo Allegrucci <lorenzo(dot)allegrucci(at)forinicom(dot)it> writes:
>> So, my main question is.. how can just a plain simple restart of postgres
>> restore the original performance (3% cpu time)?
> Are you killing off any long-running transactions when you restart?

After three days of patient waiting it looks like the common
'<IDLE> in transaction' problem..

[sorry for >80 cols]

19329 ?        S     15:54 /usr/lib/postgresql/8.3/bin/postgres -D /var/lib/postgresql/8.3/main -c config_file=/etc/postgresql/8.3/main/postgresql.conf
19331 ?        Ss     3:40  \_ postgres: writer process
19332 ?        Ss     0:42  \_ postgres: wal writer process
19333 ?        Ss    15:01  \_ postgres: stats collector process
19586 ?        Ss   114:00  \_ postgres: forinicom weadmin [local] idle
20058 ?        Ss     0:00  \_ postgres: forinicom weadmin [local] idle
13136 ?        Ss     0:00  \_ postgres: forinicom weadmin idle in transaction

My app is a Django webapp, maybe there's some bug in the Django+psycopg2 stack?

Anyway, how can I get rid those "idle in transaction" processes?
Can I just kill -15 them or is there a less drastic way to do it?

In response to


pgsql-performance by date

Next:From: Jason DictosDate: 2009-11-23 20:53:10
Subject: Best possible way to insert and get returned ids
Previous:From: Dave YouattDate: 2009-11-23 19:10:55
Subject: Re: Performance degrade running on multicore computer

pgsql-general by date

Next:From: John OylerDate: 2009-11-23 20:48:06
Subject: I need help creating a composite type with some sort of constraints.
Previous:From: Greg SmithDate: 2009-11-23 20:41:16

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