सेंटोस 5.5 पर सिंपल पोस्टग्रेएसक्यूएल 8.4.4 क्वेरी के साथ बेहद धीमी आईओ

Question

मैं देख रहा हूँ अजीब और बहुत धीमी गति से IO पैटर्न यह (आउटपुट iostat -dxk 1 /dev/xvdb1) है:

Device:         rrqm/s   wrqm/s   r/s   w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
xvdb1             0.00     0.00  0.99  0.99     7.92     3.96    12.00     1.96 2206.00 502.00  99.41

Device:         rrqm/s   wrqm/s   r/s   w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
xvdb1             0.00     0.00  0.00  0.00     0.00     0.00     0.00     1.00    0.00   0.00 100.40

Device:         rrqm/s   wrqm/s   r/s   w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
xvdb1             0.00     0.00  0.00  0.00     0.00     0.00     0.00     1.00    0.00   0.00 100.40

Device:         rrqm/s   wrqm/s   r/s   w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
xvdb1             0.00     0.00  0.99  0.00     3.96     0.00     8.00     0.99 2220.00 1004.00  99.41

Device:         rrqm/s   wrqm/s   r/s   w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
xvdb1             0.00     0.00  0.00  0.00     0.00     0.00     0.00     1.00    0.00   0.00 100.40

Device:         rrqm/s   wrqm/s   r/s   w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
xvdb1             0.00     0.99  0.99  0.00     7.92     0.00    16.00     1.14 2148.00 1004.00  99.41

Device:         rrqm/s   wrqm/s   r/s   w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
xvdb1             0.00     0.00  0.00  0.00     0.00     0.00     0.00     2.01    0.00   0.00 100.40

Device:         rrqm/s   wrqm/s   r/s   w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
xvdb1             0.00     0.00  1.00  1.00     4.00     8.00    12.00     2.01 1874.00 502.00 100.40

मुझे नहीं पता कि डिस्क का उपयोग और प्रतीक्षा इतनी अधिक क्यों है, और पढ़ने / लिखने की दर इतनी कम है। इसका क्या कारण हो सकता है?

सारणीबद्ध की जा रही तालिका में केवल कई varchar कॉलम हैं, जिनमें से एक last_name है, जो अनुक्रमित है (वास्तव lower(last_name)में अनुक्रमित है)। प्रश्न ही सरल है:

SELECT * FROM consumer_m WHERE lower(last_name) = 'hoque';

यहाँ समझा उत्पादन है:

                                           QUERY PLAN                                            
-------------------------------------------------------------------------------------------------
 Bitmap Heap Scan on consumer_m  (cost=2243.90..274163.41 rows=113152 width=164)
   Recheck Cond: (lower((last_name)::text) = 'hoque'::text)
   ->  Bitmap Index Scan on consumer_m_last_name_index  (cost=0.00..2215.61 rows=113152 width=0)
         Index Cond: (lower((last_name)::text) = 'hoque'::text)

यह भी ध्यान दें कि डेटाबेस auto_vacuum पर है, इसलिए कोई स्पष्ट वैक्यूम / विश्लेषण नहीं किया गया था।

Comments

क्या आपने अपने postgresql.conf को कस्टमाइज़ किया था? यदि CentOS में RHEL 5.x के समान ही डिफॉल्ट हैं, तो आपको पोस्टग्रेज के लिए बहुत कम मेमोरी होगी, जो बहुत सारे डिस्क IO को बाध्य कर सकती है। इस तालिका में पंक्तियाँ कितनी बड़ी हैं?

— थियागो फिगुएइरो

तालिका स्मृति में फिट होती है, जैसा कि स्पष्ट रूप से सूचकांक करता है; यह उस तरह से विभाजित किया गया था। और postgresql.conf को उचित रूप से अनुकूलित किया गया है (साझा_बर्फर्स, प्रभावी_चेची_साइज आदि)। यहां तक ​​कि अगर यह मामला नहीं था, तो मैं इस तरह के पतित प्रदर्शन की उम्मीद नहीं करूंगा।

— एहसानुल

Answer 1

तथ्य यह है कि आपके डिवाइस का /dev/xvdb1तात्पर्य है कि आप Xen के तहत चल रहे हैं। आपका संग्रहण कैसे कॉन्फ़िगर किया गया है? क्या अंतर्निहित डिवाइस के लिए विवाद है, और उसiostat पर कैसा दिखता है ?

जब तक कि आप इसे समाप्त नहीं कर सकते हैं, तब तक, यही वह जगह है जहां मैं खराब प्रदर्शन के दोष के स्पिनर को इंगित करने जा रहा हूं।

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

Comments

कोई विवाद नहीं। हालाँकि आप सही कह रहे हैं कि यह एक वर्चुअल सर्वर है, हार्ड डिस्क पूरी तरह से इस सर्वर के लिए समर्पित है, और मैं एक समय में एक ही डेटाबेस क्वेरी चला रहा हूं जिसमें कोई अन्य गहन सर्वर संचालन नहीं है। भंडारण सिर्फ एक कताई SATA डिस्क है। ध्यान दें कि मेरे पास कुछ अन्य (अलग-अलग) सर्वर / डेटाबेस हैं जिनमें बहुत समान सेटअप है, लेकिन जो कम IO के साथ तेजी से काम करते हैं, जैसा कि अपेक्षित था, समान प्रश्न / अनुक्रमण दिया गया।

— एहसानुल

क्या आप iostatडिस्क पर डोम 0 से चला सकते हैं सिर्फ यह देखने के लिए कि क्या तस्वीर समान है? क्या आप दोनों स्तरों से कुछ अन्य बुनियादी डिस्क बेंचमार्क कर सकते हैं? यह कम से कम मदद करने के लिए जहां अगले देखने के लिए संकीर्ण होगा।

— परिपक्वता

ज़रूर। जहां iostatसे चलाया जाता है, उसके आधार पर आप एक विसंगति की उम्मीद क्यों करते हैं ? क्या यह बात होनी चाहिए? मेरे पास वास्तव में अब dom0 तक सीधी पहुंच नहीं है, हालांकि मैं इसे प्राप्त कर सकता हूं। मैं fioइस बीच बेंचमार्किंग के लिए कोशिश करूँगा ।

— एहसानुल

एक बात के लिए: स्नैपशॉट ऐसी स्थिति बना सकते हैं

— ह्यूबर्ट करियो

आप सही मातृत्व थे, विवाद था, डोम 0 पर दिखा। यह संचार की समस्या थी, मेरे बॉस ने मेरी जानकारी के बिना, किसी और के प्रबंधन के तहत किसी अन्य सर्वर को हार्ड डिस्क का हिस्सा दिया था। मैं इस धारणा के तहत था कि यह समर्पित था, क्योंकि हम हमेशा इसे सेट करते हैं। मुझे लगता है कि यही कारण है कि अपनी मान्यताओं को दोबारा जांचना हमेशा महत्वपूर्ण होता है। धन्यवाद!

— एहसानुल

Answer 2

यहाँ कुछ सुझाव दिए गए हैं, कमोबेश यादृच्छिक क्रम में:

1. ऑटोसैकम को डिफ़ॉल्ट रूप से CentOS में चालू नहीं किया गया है। इसे सक्षम करने के लिए आपको कई सेटिंग्स सेट करनी होंगी। डबल जाँच तो रिक्त प्रक्रिया वास्तव में चलाता है। आवश्यक सेटिंग्स में से एक को याद करना आसान है।

2. ध्यान दें कि आपको उस क्वेरी के लिए दूसरा फ़िल्टर स्टेप करना होगा, जो आपको वापस मिलने के आधार पर महंगा हो सकता है। मैं एक सूचकांक पर विचार करूंगा जैसे:

   CREATE INDEX Consumer_m_lower_last पर Consumer_m (निचला (last_name));

   जो आपकी क्वेरी से मेल खाएगा और Recheck को हटा देगा।

3. इसके अलावा, जैसा कि mattdm बताता है, आप वर्चुअलाइज्ड वातावरण में iostat पर भरोसा नहीं कर सकते।

4. आपको शायद http://lonesysadmin.net/2008/02/21/elevatornoop/ की जाँच करनी चाहिए, अगर आपको XEN वातावरण में IO की समस्या है। लिफ्ट सेटिंग्स का प्रभाव हो सकता है, लेकिन यह बड़ा नहीं।

5. अंतर्निहित डिस्क LVM स्नैपशॉट का उपयोग कर रहा है? हालांकि यह प्रबंधन के दृष्टिकोण से बहुत उपयोगी है, यह IO प्रदर्शन को मार सकता है। यह सच है यदि आप जिस ब्लॉक डिवाइस का उपयोग कर रहे हैं वह स्नैपशॉट है, और यदि स्नैपशॉट ब्लॉक डिवाइस से लिया गया है।

Comments

सुझाव के लिए धन्यवाद। इंडेक्स वास्तव में कम (last_name) पर होता है, भले ही मैंने इंडेक्स के नाम से "लोअर" छोड़ दिया हो। इसलिए मुझे नहीं पता कि वहाँ क्यों एक जाँच चल रही है। जिस डिस्क पर माउंट किया गया है /वह वास्तव में LVM स्नैपशॉट का उपयोग कर रहा है, लेकिन वह नहीं जिस पर डेटाबेस संग्रहीत है। इसलिए मुझे नहीं लगता कि ऐसा है। मैं हालांकि आपके अन्य सुझावों पर गौर करूंगा!

— एहसानुल

Answer 3

मुझे शक है कि यह PostgreSQL के साथ एक समस्या है, और डिस्क IO के साथ सिर्फ एक समस्या होने की संभावना है। जैसा कि एक अन्य उत्तर से टिप्पणियों का उल्लेख है, अगर यह एक डिस्क IO मुद्दा है, तो आपको वास्तव में DOM0 से मापना चाहिए ताकि आपको जो कुछ भी हो रहा है उसकी एक तस्वीर मिल जाए।

मुझे थोड़ी देर पहले एक समान समस्या थी और यह डिस्क नियंत्रक के साथ एक मुद्दा बन गया। बहुत धीमी डिस्क का उपयोग डिस्क IO की प्रतीक्षा करते समय सिस्टम को अड़चन का कारण बन रहा था (जो कि बहुत अधिक लोड औसत के रूप में दिखाई देता है और कई बार प्रतीक्षा करता है, लेकिन यह भी प्रक्रिया का कारण बनता है कि डिस्क का इंतजार करने से अधिक सीपीयू का उपभोग करने की तुलना में वे अन्यथा कर सकते हैं। यह पता चला है कि कर्नेल। नियंत्रक को ठीक से नहीं पहचान रहा था और तेजी से एक के बजाय पुराने स्कूल आईडीई नियंत्रक पर वापस गिर रहा था।

फिक्स को बूट करना था

hda=noprobe hda=none 

/etc/grub.conf में कर्नेल स्ट्रिंग के अंत में। (बेशक, आपके पास सभी डिस्क जोड़ें, अला: hdc=noprobe, hdc=none, hdd=...)

Comments

धन्यवाद, लेकिन यह पता चला है कि यह इस मामले में बहुत ज्यादा शांत था। किसी भी तरह वोट करें।

— एहसानुल