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