आँकड़े कलेक्टर प्रक्रिया को पोस्टग्रेज करके बहुत अधिक I / O उत्पन्न होता है

10

मैं स्थानीय पोस्टग्रेज डेटाबेस रखने वाली कई वर्चुअल मशीनों के साथ XenServer का उपयोग कर रहा हूं। यहां तक कि जब सभी एप्लिकेशन अप्रयुक्त होते हैं और डेटाबेस निष्क्रिय होते हैं, तो प्रत्येक vm निरंतर संग्रहण नेटवर्क ट्रैफ़िक का कारण बनता है जो iscsi संग्रहण डिवाइस के प्रदर्शन को नीचा दिखाता है।

चलाने के बाद iotopमैंने नोट किया है कि पोस्टग्रैट्स स्टैट्स कलेक्टर प्रक्रिया प्रक्रिया डिस्क पर लगभग 2 एमबीटी / एस की दर से लगातार लिख रही है।

मैंने तब संपादन करके आँकड़े एकत्र करना अक्षम कर दिया /etc/postgresql/8.4/main/postgresql.conf:

#------------------------------------------------------------------------------
# RUNTIME STATISTICS
#------------------------------------------------------------------------------

# - Query/Index Statistics Collector -

track_activities = off
track_counts = off
...

जैसा कि http://www.postgresql.org/docs/8.4/static/runtime-config-statistics.htm में सुझाया गया है ।

इसने निरंतर लेखन को समाप्त कर दिया, लेकिन क्या आँकड़ों को बंद करने के कोई नुकसान हैं?

या क्या मुझे डिस्क / नेटवर्क ट्रैफ़िक से बचने के लिए pg_stat_tmp निर्देशिका को रैमडिस्क पर रखना चाहिए?

सिस्टम एक अप-टू-डेट डेबियन 6.0.7 (निचोड़) है जिसमें 8.4 और लगभग 50 तालिकाओं वाले 20 डेटाबेस हैं, कुल डंप फ़ाइल का आकार 100 एमबीटी से कम है।

— nn4l
स्रोत

7

चूंकि PostgreSQL को अपग्रेड करना एक विकल्प नहीं है, इसलिए मैंने pg_stat_tmp निर्देशिका को tmpfs फाइल सिस्टम पर रखने की कोशिश की है, जिसने एक महत्वपूर्ण प्रदर्शन सुधार दिया है। मैं अब इसे कुछ दर्जन सिस्टमों पर एक-दो महीने से चला रहा हूं।

ऐसा करने के लिए, बस अपने / etc / fstab फ़ाइल में tmpfs के साथ pg_stat_tmp माउंट करें:

# <file system> <mount point>                                <type>  <options>  <dump>  <pass>
tmpfs           /var/lib/postgresql/8.4/main/pg_stat_tmp     tmpfs   defaults,noatime,mode=1777,uid=postgres,gid=postgres,nosuid,nodev 0 0

— nn4l
स्रोत

मैंने यह Postgresql 9.1 के लिए किया था। मेरे एक सर्वर में पूरे दिन में लगातार 1 एमबी / एस लिखा था। इसने इसे लगभग कुछ भी नहीं होने दिया। यह द्वारा अनुमोदित है डॉक्स "... एक रैम आधारित फाइल सिस्टम पर इस ओर इशारा करते हुए शारीरिक आई / ओ आवश्यकताओं में कमी होगी और बेहतर प्रदर्शन करने के लिए नेतृत्व कर सकते हैं।":, BTW

— Halfgaar

0

PostgreSQL को अपग्रेड करें। पूर्ण न्यूनतम पर सुनिश्चित करें कि आप नवीनतम 8.4 रिलीज पर हैं; यदि वह इसे संबोधित नहीं करता है और ऐसा करने के लिए व्यावहारिक है तो आपको संभवतः 9.2 में अपग्रेड करना चाहिए। सांख्यिकी कलेक्टर के आसपास कम से कम कुछ मुद्दों को 8.4 के बाद से संबोधित किया गया है, और लगभग एक साल में जीवन के अंत तक पहुंच जाएगा । आप pgsql- सामान्य मेलिंग सूची अभिलेखागार खोज कर अधिक जानकारी प्राप्त करने में सक्षम हो सकते हैं ।

आपको 8.4 से 9.2 के बीच अपग्रेड करने में बहुत अधिक समस्याएं नहीं होनी चाहिए, हालांकि हमेशा की तरह आपको प्रत्येक .0 रिलीज़ इनबेटइन (9.0, 9.1 और 9.2) के लिए रिलीज़ नोट्स के अपग्रेड अनुभाग को पढ़ना चाहिए । पर विशेष ध्यान दें standard_conforming_stringsऔर bytea_output।

— क्रेग रिंगर
स्रोत

0

यहां भी यही समस्या। मैं भी विकलांग track_*और इतने पर।

दुष्प्रभाव यह है कि autovacuumइस एकत्र किए गए डेटा का उपयोग आग लगाने के लिए किया जाता है।

इसलिए, मैं रात के शेड्यूल का ध्यान रखता हूं vacuumdb।

अन्य समाधान autovacuum_naptimeसिस्टम आराम करने के लिए पर्याप्त उच्च सेट करना है।

— Gelma
स्रोत