PostgreSQL 유휴 트랜잭션 진단 및 읽기 pg_locks

Question

설정 : Postgres 8.3.6을 실행하는 공유 DB에 연결하는 mod_wsgi, Apache 및 pgbouncer를 실행하는 여러 웹 서버가 있습니다. 응용 프로그램이 장고를 실행 중입니다.

오랫동안 놀고있는 DB의 '유휴 트랜잭션'쿼리. 물론

SELECT query_start, procpid, client_addr, current_query FROM pg_stat_activity 
WHERE query_start < NOW() - interval '5 minutes'; 

대부분의 결과를 사용하기 위해 개방 유지하고있다 pgbouncer 단지 IDLE 연결입니다,하지만 때로는 쿼리이 된 '거래 IDLE'가있을 것입니다 : 그들을보기 위해, 나는 이런 식으로 뭔가를 실행하겠습니다 . 나는 이것이 뭔가를 기다리고있는 쿼리 트랜잭션이 있거나 BEGIN이 있지만 COMMIT 또는 ROLLBACK에 도달하지 않은 트랜잭션을 의미한다는 것을 이해합니다. 결과는 내가 그렇게 같은 외모를 얻을

select pg_class.relname, pg_locks.transactionid, pg_locks.mode, 
     pg_locks.granted as "g", pg_stat_activity.current_query, 
     pg_stat_activity.query_start, 
     age(now(),pg_stat_activity.query_start) as "age", 
     pg_stat_activity.procpid 
from pg_stat_activity,pg_locks 
left outer join pg_class on (pg_locks.relation = pg_class.oid) 
where pg_locks.pid=pg_stat_activity.procpid 
and pg_stat_activity.procpid = <AN IDLE TRANSACTION PROCESS> 
order by query_start; 

많은 시간을 :

relname | transactionid |  mode  | g |  current_query  |   query_start   |  age  | client_addr | procpid 
---------+---------------+-----------------+---+-----------------------+------------------------------+-----------------+----------------+--------- 
     |    | AccessShareLock | t | <IDLE> in transaction | 2010-07-22 15:33:11.48136-04 | 00:23:35.029045 | 192.168.100.99 | 1991 
     |    | AccessShareLock | t | <IDLE> in transaction | 2010-07-22 15:33:11.48136-04 | 00:23:35.029045 | 192.168.100.99 | 1991 
     |    | AccessShareLock | t | <IDLE> in transaction | 2010-07-22 15:33:11.48136-04 | 00:23:35.029045 | 192.168.100.99 | 1991 
     |    | AccessShareLock | t | <IDLE> in transaction | 2010-07-22 15:33:11.48136-04 | 00:23:35.029045 | 192.168.100.99 | 1991 
     |    | AccessShareLock | t | <IDLE> in transaction | 2010-07-22 15:33:11.48136-04 | 00:23:35.029045 | 192.168.100.99 | 1991 
     |    | AccessShareLock | t | <IDLE> in transaction | 2010-07-22 15:33:11.48136-04 | 00:23:35.029045 | 192.168.100.99 | 1991 
     |    | AccessShareLock | t | <IDLE> in transaction | 2010-07-22 15:33:11.48136-04 | 00:23:35.029045 | 192.168.100.99 | 1991 
     |    | AccessShareLock | t | <IDLE> in transaction | 2010-07-22 15:33:11.48136-04 | 00:23:35.029045 | 192.168.100.99 | 1991 
     |    | ExclusiveLock | t | <IDLE> in transaction | 2010-07-22 15:33:11.48136-04 | 00:23:35.029045 | 192.168.100.99 | 1991 
     |    | AccessShareLock | t | <IDLE> in transaction | 2010-07-22 15:33:11.48136-04 | 00:23:35.029045 | 192.168.100.99 | 1991 
(10 rows) 

I를

내 다음 단계는 프로세스가 기다리고 무엇을 결정하기 위해 pg_locks를 사용하려고했다 이 글을 읽는 방법을 모르겠다. (실제로 pg_locks를 이해하지 못했기 때문이다.) 이름이 없으니 아무 것도 기다리지 않는다고 말하는 겁니까? 나는 그것이 '사실'이라고 인정한다면, 그것은 자물쇠를 가지고 있다고 생각했다. 이 모든 결과가 주어지기 때문에, pg_locks는 기다리고있는 것보다 내가 가지고있는 잠금을 보여 줍니까?

지금 당장은 아파치를 재시작하여 '수정'하고 있는데, 이는 트랜잭션을 느슨하게하는 것처럼 보입니다.하지만 분명히 실제 해결책은 아닙니다. 나는 Postgres가 나를 찾아 낼 곳을 찾고 있는데, 특히 장고는 연결과 트랜잭션을 자동으로 관리해야하기 때문에. 이 문제를 볼 이유

장고를 들어

Answer 1

특히,이 항목의 자세한 사항 : Threaded Django task...

내가 "특히"여기 말을 진짜 문제는 트랜잭션의 모든 시간을 작업 웹 프레임 워크/드라이버 /으로 ORMs 때문에 기반 커맨드 모드에서 실제로 실행되어야하고 필요할 때만 트랜잭션의 필요성을 처리해야 할 때마다 (그리고 때로는 모든 freakin 'SELECT 쿼리 후에 롤백을 호출합니다.) 아파치 :: 세션 PostgreSQL 퍼시스턴스 모듈은 가비지 수집시에만 트랜잭션을 종료하기 때문에 적어도 몇 년 전의 재앙이었습니다. Yikes!