2013-12-11 9 views
18

मैं यह समझने की कोशिश कर रहा हूं कि ~ 30 निष्क्रिय पोस्टग्रेस प्रक्रिया सामान्य उपयोग के बाद इतनी प्रक्रिया-विशिष्ट स्मृति क्यों लेती है। मैं पोस्टग्रेस 9.3.1 और सेंटोस रिलीज 6.3 (फ़ाइनल) का उपयोग कर रहा हूं। top का उपयोग करना, मैं गैर साझा (आरईएस - SHR) के (औसत ~ 200MB) 300MB अप करने के लिए प्रयोग कर रहे हैं कि postgres कनेक्शन के कई देख सकते हैं स्मृति:निष्क्रिय पोस्टग्रेस प्रक्रियाएं बहुत मेमोरी ले रही हैं

PID USER  PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 
3534 postgres 20 0 2330m 1.4g 1.1g S 0.0 20.4 1:06.99 postgres: deploy mtalcott 10.222.154.172(53495) idle 
9143 postgres 20 0 2221m 1.1g 983m S 0.0 16.9 0:14.75 postgres: deploy mtalcott 10.222.154.167(35811) idle 
6026 postgres 20 0 2341m 1.1g 864m S 0.0 16.4 0:46.56 postgres: deploy mtalcott 10.222.154.167(37110) idle 
18538 postgres 20 0 2327m 1.1g 865m S 0.0 16.1 2:06.59 postgres: deploy mtalcott 10.222.154.172(47796) idle 
1575 postgres 20 0 2358m 1.1g 858m S 0.0 15.9 1:41.76 postgres: deploy mtalcott 10.222.154.172(52560) idle 

29 के बारे में कुल निष्क्रिय कनेक्शन हैं। ये निष्क्रिय कनेक्शन तब तक स्मृति में बढ़ते रहते हैं जब तक मशीन स्वैप का उपयोग शुरू नहीं करती है, फिर प्रदर्शन बंद हो जाता है। जैसा कि अपेक्षित है, कनेक्शन को रीसेट करने से प्रक्रिया-विशिष्ट स्मृति साफ़ हो जाती है। जब मैं समय-समय पर पुन: कनेक्ट करता हूं, उसी मशीन पर कनेक्शन की एक ही संख्या केवल 20% स्मृति (0 स्वैप के साथ) का उपयोग करती है। इन प्रक्रियाओं को किस प्रकार की जानकारी मिल रही है? मैं लंबे समय से चलने की उम्मीद करता हूं, निष्क्रिय पोस्टग्रेस प्रक्रियाओं को ब्रांड नए, निष्क्रिय लोगों के समान स्मृति उपयोग करने की प्रक्रिया करता है।

ध्यान देने योग्य मूल्य: मैं स्कीमा का उपयोग कर भारी रूप से उपयोग कर रहा हूं। मेरे ऐप के हर अनुरोध पर, मैं search_path को सेट और रीसेट कर रहा हूं।

उत्तर

12

इन प्रक्रियाओं को किस प्रकार की जानकारी मिल रही है? मैं लंबे समय से चलने की उम्मीद करता हूं, निष्क्रिय पोस्टग्रेस प्रक्रियाओं को ब्रांड नए, निष्क्रिय लोगों के समान स्मृति उपयोग करने की प्रक्रिया करता है।

  • relcache (संबंध वर्णनकर्ता)
  • catcache (सिस्टम सूची प्रविष्टियों)
  • संकलित:

वास्तव में काफी कुछ चीजें हैं जो Postgres स्थानीय स्मृति में कैश होगा एक बार यह उनके लोड होते ही हैं plpgsql कार्यों के लिए पेड़

अधिकांश उपयोग मामलों के लिए, ये सभी नगण्य राशि तक जोड़ते हैं। यहां की कुंजी स्कीमा का भारी उपयोग और रिसाव पर प्रभाव था। इस डेटाबेस में ~ 500 स्कीमा हैं, प्रत्येक एक ही ~ 90 टेबल के साथ। पोस्टग्रेज़ के लिए, भले ही स्कीमा सभी समान हैं, यह 45,000 टेबल (500 * 9 0) तक काम करता है।

प्रत्येक अनुरोध ने स्मृति में कुछ तालिकाओं के संबंध वर्णनकर्ताओं को कैश किया (अक्सर इससे पहले अनुरोध से अलग स्कीमा में), धीरे-धीरे रिलाक भरना। दुर्भाग्यवश, Postgres does not offer a way to limit the size of these caches, क्योंकि ओवरहेड शायद अधिकांश उपयोग मामलों के लिए प्रतिकूल होगा।

संभावित समाधान:

  • रिकनेक्ट अनुरोध की एक निश्चित संख्या के बाद
  • pgpool-II या PgBouncer
का उपयोग कर postgres कनेक्शन की संख्या पर एक छत डाल करने के लिए और अधिक स्मृति जोड़ें
  • कनेक्शन पूलिंग

    Postgres mailing lists पर इस के लिए सहायता के लिए टॉम लेन और मर्लिन मोनक्योर के लिए धन्यवाद।

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