IO ช้ามากพร้อม PostgreSQL แบบง่าย 8.4.4 ข้อความค้นหาบน Centos 5.5

รูปแบบ 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 ดังนั้นจึงไม่มีการดูด / วิเคราะห์อย่างชัดเจน

ความจริงที่ว่าอุปกรณ์ของคุณ/dev/xvdb1แสดงว่าคุณกำลังใช้งาน Xen อยู่ พื้นที่เก็บข้อมูลของคุณมีการกำหนดค่าอย่างไร? มีการต่อสู้สำหรับอุปกรณ์พื้นฐานและวิธีการที่ไม่iostatดูในที่ ?

ถ้าคุณไม่สามารถกำจัดสิ่งที่เป็นไปได้นั่นคือสิ่งที่ฉันจะชี้ให้เห็นถึงความผิดของตัวหมุนที่มีประสิทธิภาพต่ำ

โดยทั่วไปวิธีการโดยรวมในการแก้ปัญหาเรื่องประสิทธิภาพเช่นนี้คือการคิดเกี่ยวกับเลเยอร์ทั้งหมดที่เกิดปัญหาคอขวดจากนั้นจึงออกแบบการทดสอบเพื่อกำจัดแต่ละปัญหาจนกว่าคุณจะแยกแยะปัญหา

นี่คือคำแนะนำบางอย่างในลำดับแบบสุ่มมากหรือน้อย:

1. Autovacum ไม่เปิดตามค่าเริ่มต้นใน CentOS มีการตั้งค่าหลายอย่างที่คุณต้องตั้งค่าเพื่อเปิดใช้งาน ตรวจสอบอีกครั้งเพื่อให้กระบวนการ vacum ทำงานจริง มันง่ายที่จะพลาดหนึ่งในการตั้งค่าที่จำเป็น

2. โปรดทราบว่าคุณต้องทำขั้นตอนที่สองของตัวกรองสำหรับแบบสอบถามซึ่งอาจมีราคาแพงขึ้นอยู่กับสิ่งที่คุณได้รับกลับ ฉันจะพิจารณาดัชนีเช่น:

   สร้าง INDEX consumer_m_lower_last ON consumer_m (ต่ำกว่า (นามสกุล)

   ซึ่งจะจับคู่กับแบบสอบถามของคุณและลบการตรวจสอบอีกครั้ง

3. นอกจากนี้ดังที่ mattdm ชี้ให้เห็นคุณไม่สามารถเชื่อถือ iostat ในสภาพแวดล้อมเสมือนจริง

4. คุณควรตรวจสอบhttp://lonesysadmin.net/2008/02/21/elevatornoop/หากคุณมีปัญหา IO ในสภาพแวดล้อม XEN การตั้งค่าลิฟต์อาจมีผลกระทบ แต่จะไม่ใหญ่มาก

5. ดิสก์อ้างอิงใช้สแน็ปช็อต LVM หรือไม่ ในขณะที่สิ่งนี้มีประโยชน์มากจากมุมมองของผู้บริหาร แต่ก็สามารถฆ่าประสิทธิภาพของ IO ได้ สิ่งนี้เป็นจริงทั้งในกรณีที่อุปกรณ์บล็อกที่คุณลงชื่อเป็นสแน็ปช็อตและหากสแน็ปช็อตนั้นถูกนำไปใช้กับอุปกรณ์บล็อก

ฉันสงสัยว่านี่เป็นปัญหาของ PostgreSQL และน่าจะเป็นปัญหาของ Disk IO เท่านั้น ตามความคิดเห็นจากคำตอบอื่น ๆ ที่กล่าวถึงหากเป็นปัญหาของดิสก์ IO คุณควรวัดจาก Dom0 เพื่อให้ได้ภาพทุกอย่างที่เกิดขึ้น

ฉันมีปัญหาที่คล้ายกันมากในขณะที่กลับและมันก็กลายเป็นปัญหากับตัวควบคุมดิสก์ การเข้าถึงดิสก์ที่ช้ามากทำให้ระบบเกิดปัญหาคอขวดขณะรอดิสก์ IO (ซึ่งแสดงว่ามีโหลดเฉลี่ยสูงมากและรอเวลา แต่ยังทำให้กระบวนการรอให้ดิสก์ใช้ CPU มากกว่าที่พวกเขาต้องการ ไม่รู้จักตัวควบคุมอย่างถูกต้องและกลับไปที่ตัวควบคุม IDE ของโรงเรียนเก่าแทนที่จะเป็น SATA ที่รวดเร็ว

การแก้ไขคือการบูตด้วย

hda=noprobe hda=none 

ที่ส่วนท้ายของสตริงเคอร์เนลใน /etc/grub.conf (แน่นอนเพิ่มดิสก์ทั้งหมดที่คุณมี Ala: hdc=noprobe, hdc=none, hdd=... )