पोस्टग्रेएसक्यूएल निष्क्रिय लेनदेन निदान और पढ़ना में pg_locks

सेटअप: एकाधिक वेबसर्वर, चल रहे mod_wsgi, अपाचे, और pgbouncer जो साझा डीबी चल रहे Postgres 8.3.6 से कनेक्ट होता है। आवेदन Django चल रहा है।पोस्टग्रेएसक्यूएल निष्क्रिय लेनदेन निदान और पढ़ना में pg_locks

हम क्या देख रहे हैं: डीबी पर लेनदेन में निष्क्रिय 'प्रश्न जो लंबे समय तक बाहर निकलते हैं।

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

पाठ्यक्रम के अधिकांश परिणाम सिर्फ निष्क्रिय कनेक्शन pgbouncer कि उपयोग के लिए खुला रखने है रहे हैं, लेकिन कभी कभी प्रश्नों इन पुराने 'लेन-देन में निष्क्रिय' हो जाएगा: उन्हें देखने के लिए में, मैं कुछ इस तरह चलाएंगे । मैं समझता हूं कि इसका मतलब है कि एक प्रश्न लेनदेन है जो किसी चीज़ की प्रतीक्षा कर रहा है, या कुछ ऐसा है जो BEGIN था लेकिन COMMIT या रोलबैक तक नहीं पहुंचा है।

मेरे अगले कदम pg_locks उपयोग करने के लिए निर्धारित करने के लिए क्या प्रक्रिया पर इंतज़ार कर रहा है की कोशिश करना था:

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)

मैं मुझे यकीन नहीं है कि इसे कैसे पढ़ा जाए (मुझे लगता है कि यह वास्तव में pg_locks को समझने से उत्पन्न नहीं होता है)। कोई रिलेनाम नहीं है, तो क्या यह कह रहा है कि यह कुछ भी इंतजार नहीं कर रहा है? मैंने सोचा कि अगर दिया गया 'सत्य' था, तो यह ताला था। चूंकि ये सभी परिणाम दिए गए हैं, क्या pg_locks मुझे ताले दिखा रहे हैं जो इसके इंतजार के बजाय है?

अभी मैं अपाचे को पुनरारंभ करके इसे 'ठीक कर रहा हूं', जो लेनदेन को ढीला लगता है, लेकिन जाहिर है कि यह वास्तविक समाधान नहीं है। मैं पोस्टग्रेस की तलाश में हूं कि मुझे यह पता लगाने के लिए कहां देखना है, खासकर जब से Django को अपने कनेक्शन और लेनदेन को स्वचालित रूप से प्रबंधित करना है।

स्रोत

2010-07-22 KRH

एक संभावित कारण है कि आप relname में कुछ भी नहीं देख रहे हैं यह है कि आप गलत डेटाबेस से जुड़े हुए हैं। कनेक्शन को चलाने वाले कनेक्शन को उसी डीबी से कनेक्ट करने की आवश्यकता होती है, जिसमें संबंध है, या यह आपको नाम नहीं दे पाएगा। मुझे लगता है कि आप "पोस्टग्रेस" डेटाबेस से जुड़े हुए हैं या इसलिए क्वेरी चलाते समय ... –

Django के लिए विशेष रूप से, इस प्रविष्टि के विवरण तुम क्यों इस मुद्दे को देखें:

Threaded Django task...

मैं "विशेष" यहाँ का कहना है कि क्योंकि वास्तविक समस्या वेब चौखटे/ड्राइवरों/एक सौदे में हर समय काम कर ORMs है -आधारित मोड (और कभी-कभी प्रत्येक freakin 'चयन क्वेरी के बाद रोलबैक को कॉल करना) जब उन्हें वास्तव में ऑटो-कमिट मोड में चलाना चाहिए और केवल आवश्यक आधार पर लेन-देन की आवश्यकता को संभालना चाहिए। अपाचे :: सत्र PostgreSQL दृढ़ता मॉड्यूल एक आपदा था (कम से कम कुछ साल पहले) क्योंकि यह कचरा इकट्ठा होने पर केवल लेनदेन बंद कर दिया गया था। ओह!

स्रोत

2010-07-22 22:15:22

जैसा कि मैं समझता हूं कि एक व्यक्ति, वह यह पाया था कि उसे मैन्युअल रूप से अनुसूचित क्रॉन नौकरियों के संदर्भ में कनेक्शन बंद करने की आवश्यकता है, यानी जहां Django का कनेक्शन निकट संकेत होता है जो अनुरोध किया जाता है जब कोई अनुरोध नहीं किया जाता है। ये निष्क्रिय लेन-देन वेबसर्वर से आ रहे हैं जो किसी भी क्रॉन/स्वतंत्र Django प्रक्रियाओं को नहीं चला रहे हैं। – KRH

पोस्टग्रेएसक्यूएल निष्क्रिय लेनदेन निदान और पढ़ना में pg_locks

उत्तर

संबंधित मुद्दे