PostgreSQL pg_stat_activity แสดง COMMIT


11

เมื่อเร็ว ๆ นี้เราได้เปลี่ยนเซิร์ฟเวอร์ฐานข้อมูลของเราด้วยเครื่องที่อัพเกรดด้วยซีพียูแกน 4 x Quad และ RAM ขนาด 32Gb นอกจากนี้เรายัง repurposed กล่องเก่าของเราเพื่อใช้เป็นทาสกับการจำลองแบบการสตรีม กล่องทั้งสองกำลังเรียกใช้ CentOS 6.3 และ PostgreSQL 9.2 Postgres เป็นสิ่งเดียวที่ทำงานในแต่ละกล่อง

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

เราได้ลองวินิจฉัยว่าเกิดอะไรขึ้นและหายไปเล็กน้อย ผลลัพธ์จากการวิ่งperfแสดงบางอย่างที่คล้ายกับด้านล่างและฉันไม่รู้ว่ามัน0x347ba9หมายถึงอะไร

+  41.40%       48154  postmaster  0x347ba9         f 0x347ba9                                   
+   9.55%       10956  postmaster  0x2dc820         f set_config_option                          
+   8.64%        9946  postmaster  0x5a3d4          f writeListPage     
+   5.75%        6609  postmaster  0x5a2b0          f ginHeapTupleFastCollect                    
+   2.68%        3084  postmaster  0x192483         f build_implied_join_equality                
+   2.61%        2990  postmaster  0x187a55         f build_paths_for_OR                         
+   1.86%        2131  postmaster  0x794aa          f get_collation_oid                          
+   1.56%        1822  postmaster  0x5a67e          f ginHeapTupleFastInsert                     
+   1.53%        1766  postmaster  0x1929bc         f distribute_qual_to_rels                    
+   1.33%        1558  postmaster  0x249671         f cmp_numerics

ไม่มีข้อความค้นหาใดที่ดำเนินการโดยแอพมีความซับซ้อนเป็นพิเศษโดยอธิบายแผนการที่ใช้เวลาไม่เกิน 1 วินาที (ส่วนใหญ่เร็วกว่ามาก) นอกจากนี้ในขณะที่สิ่งนี้เกิดขึ้นเมื่อการรับส่งข้อมูลเริ่มขึ้นเราไม่ได้พูดถึงปริมาณการใช้งานจำนวนมาก (เครื่องเก่าที่เคยสามารถจัดการกับมันได้อย่างง่ายดาย)

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

การกำหนดค่าดิสก์:

  • Perc 6i RAID Controller
  • 5 x 146GB 15K SAS ไดรฟ์
  • กำหนดค่าเป็น 2x146GB RAID-1 สำหรับ WAL และ 3x146GB RAID-5 สำหรับระบบและข้อมูล

ปรับปรุง:

ด้านล่างคือเอาต์พุต VMStat เมื่อระบบทำงานตามปกติและเมื่อ CPU ทำงาน เมื่อมีปัญหาขัดจังหวะดูเหมือนจะพุ่งสูงขึ้น

ระหว่างการทำงานปกติ:

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ ---timestamp---
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 18938590 303763 21947154    0    0    28    52 7466 12649  2  1 97  0  0   2013-01-14 16:03:25 EST
 0  0      0 18938396 303763 21947154    0    0     0    19 7107 12679  2  0 98  0  0   2013-01-14 16:03:35 EST
 1  0      0 18938904 303763 21947162    0    0     0    54 7042 12708  1  1 99  0  0   2013-01-14 16:03:45 EST
 1  0      0 18938520 303763 21947260    0    0    33    66 7120 12738  1  1 99  0  0   2013-01-14 16:03:55 EST

เมื่อการใช้งาน CPU สูง:

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ ---timestamp---
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
343 0      0 32680468 226279 11339612    0    0     0   214 26692 12225 80  20  0  0  0   2013-01-11 16:45:53 EST
374 1      0 32673764 226291 11340345    0    0     0    77 54893 11572 80  20  0  0  0   2013-01-11 16:46:03 EST
383 0      0 32616620 226304 11340956    0    0     0   102 55540 12922 82  18  0  0  0   2013-01-11 16:46:13 EST
315 0      0 32602038 226320 11341378    0    0     0    79 54539 12441 82  18  0  0  0   2013-01-11 16:46:23 EST

กล่องใหม่มีดิสก์ประเภทใด สิ่งนี้เกิดขึ้นกับทั้งสองโหนดหรือเพียงหนึ่งโหนดเท่านั้น
Trygve Laugstøl

@trygvis - ฉันอัปเดตคำถามด้วยรายละเอียดดิสก์ ปัญหานี้เกิดขึ้นบนโหนดมาสเตอร์ ฉันไม่ได้พยายามโปรโมต Slave และควบคุมปริมาณการใช้งานโดยตรงดังนั้นฉันไม่แน่ใจว่าเป็นปัญหาที่นั่นหรือไม่ภายใต้สถานการณ์เดียวกัน ในฐานะที่เป็นทาสเครื่องดูเหมือนจะไม่พบปัญหาใด ๆ
jcern

2
พิจารณาใช้perfเครื่องมือในการทำโปรไฟล์ทั้งระบบและทำโปรไฟล์ PostgreSQL ดูว่าการใช้งาน CPU เกิดขึ้นที่ใด BTW การจัดรูปแบบของลำดับที่ 2 ของคุณมีการพันกันvmstatอย่างไร้ความหวังและคอลัมน์ที่ 1 นั้นไม่ตรงแนวดังนั้นจึงยากต่อการอ่าน ทดสอบเพื่อดูว่าการcommit_delayเพิ่มสิ่งปรับปรุงหรือไม่ ตรวจสอบว่าคอนโทรลเลอร์ RAID ของคุณมีแคชการเขียนสำรองข้อมูลที่สำรองไว้หรือไม่และรับได้หรือไม่ ใช้เวลานานiowaitแค่ไหน? นี่ดูเหมือนจะเป็นการใช้งาน CPU ในการรายงานบางอย่าง แต่ไม่ใช่จริงๆ
Craig Ringer

@CraigRinger คอนโทรลเลอร์มีแคชการเขียนสำรองแบตเตอรี่และเปิดใช้งานอยู่ในปัจจุบัน การรอคอยจาก iostat ยังคงอยู่ในหลักเดียวสองหลักที่ต่ำ เราจะพยายามทำโปรไฟล์ให้สมบูรณ์ยิ่งขึ้นต่อไป ฉันยังแก้ไขการจัดรูปแบบของ VMS ที่สองขอบคุณที่ชี้ให้เห็น
jcern

คำตอบ:


11

หลังจากการวินิจฉัยเพิ่มเติมและ Googling เราพบบทความนี้ที่อธิบายอาการต่าง ๆ ที่เราพบ สาเหตุที่แท้จริงของปัญหาของพวกเขา (และจากสิ่งที่เราสามารถบอกได้ว่าของเราด้วย) เกี่ยวข้องกับการTransparent Huge Pagesดำเนินการ

หลังจากปิดใช้งานTransparent Huge Pagesด้วยคำสั่งนี้:

echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled

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

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.