พื้นฐานของการตรวจสอบ PostgreSQL อเล็กเซย์ เลซอฟสกี้

ฉันขอแนะนำให้คุณอ่านสำเนารายงานของ Alexey Lesovsky จาก Data Egret “พื้นฐานของการตรวจสอบ PostgreSQL”

ในรายงานนี้ Alexey Lesovsky จะพูดถึงประเด็นสำคัญของสถิติหลังการประชุม ความหมาย และเหตุใดจึงควรนำเสนอประเด็นเหล่านี้ในการติดตาม เกี่ยวกับกราฟที่ควรอยู่ในการติดตาม วิธีเพิ่ม และวิธีตีความ รายงานนี้จะเป็นประโยชน์สำหรับผู้ดูแลระบบฐานข้อมูล ผู้ดูแลระบบ และนักพัฒนาที่สนใจในการแก้ไขปัญหาของ Postgres

ฉันชื่อ Alexey Lesovsky ฉันเป็นตัวแทนของบริษัท Data Egret

คำไม่กี่คำเกี่ยวกับตัวฉัน ฉันเริ่มต้นจากการเป็นผู้ดูแลระบบเมื่อนานมาแล้ว

ฉันจัดการระบบ Linux ที่แตกต่างกันทุกประเภท ทำงานกับสิ่งต่าง ๆ ที่เกี่ยวข้องกับ Linux เช่น การจำลองเสมือน การตรวจสอบ ทำงานกับพรอกซี ฯลฯ แต่เมื่อถึงจุดหนึ่ง ฉันเริ่มทำงานกับฐานข้อมูล PostgreSQL มากขึ้น ฉันชอบเขามาก และเมื่อถึงจุดหนึ่งฉันก็เริ่มทำงานบน PostgreSQL เกือบตลอดเวลาทำงาน และฉันก็ค่อยๆ กลายเป็น PostgreSQL DBA

และตลอดอาชีพของฉัน ฉันสนใจหัวข้อสถิติ การตรวจสอบ และการตรวจวัดทางไกลมาโดยตลอด และตอนที่ฉันเป็นผู้ดูแลระบบ ฉันทำงานอย่างใกล้ชิดกับ Zabbix และฉันก็เขียนสคริปต์ชุดเล็ก ๆ เช่น zabbix-ส่วนขยาย. เขาค่อนข้างโด่งดังในสมัยของเขา และที่นั่นสามารถตรวจสอบสิ่งสำคัญที่แตกต่างกันมาก ไม่เพียงแต่ Linux เท่านั้น แต่ยังรวมถึงส่วนประกอบต่างๆ ด้วย

ตอนนี้ฉันกำลังทำงานกับ PostgreSQL ฉันกำลังเขียนอีกสิ่งหนึ่งที่ช่วยให้คุณทำงานกับสถิติ PostgreSQL ได้ มันถูกเรียกว่า pgCenter (บทความเกี่ยวกับHabré - สถิติหลังการเกรสโดยไม่ต้องประหม่าและตึงเครียด).

บันทึกเบื้องต้นเล็กน้อย ลูกค้าของเราลูกค้าของเรามีสถานการณ์อะไรบ้าง? มีอุบัติเหตุบางอย่างที่เกี่ยวข้องกับฐานข้อมูล และเมื่อฐานข้อมูลถูกกู้คืนแล้ว หัวหน้าแผนก หรือหัวหน้าฝ่ายพัฒนาจะมาบอกว่า “เพื่อน ๆ เราต้องติดตามฐานข้อมูลให้ดีเพราะมีเรื่องเลวร้ายเกิดขึ้นและเราจำเป็นต้องป้องกันไม่ให้สิ่งนี้เกิดขึ้นในอนาคต” และนี่คือการเริ่มต้นกระบวนการที่น่าสนใจในการเลือกระบบตรวจสอบหรือปรับระบบตรวจสอบที่มีอยู่เพื่อให้คุณสามารถตรวจสอบฐานข้อมูลของคุณ - PostgreSQL, MySQL หรืออื่นๆ และเพื่อนร่วมงานเริ่มแนะนำว่า:“ ฉันได้ยินมาว่ามีฐานข้อมูลเช่นนั้น ลองใช้มันดูสิ” เพื่อนร่วมงานเริ่มโต้เถียงกัน และท้ายที่สุดปรากฎว่าเราเลือกฐานข้อมูลบางประเภท แต่การตรวจสอบ PostgreSQL นั้นค่อนข้างแย่และเราจะต้องเพิ่มบางอย่างอยู่เสมอ นำพื้นที่เก็บข้อมูลบางส่วนจาก GitHub โคลนพวกมัน ปรับเปลี่ยนสคริปต์ และปรับแต่งมันด้วยวิธีใดวิธีหนึ่ง และสุดท้ายก็กลายเป็นงานแบบ manual นั่นเอง

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

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

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

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

ดังนั้นจากการปฏิบัติของเรา เมื่อเราไปหาลูกค้า การตรวจสอบมักจะไม่สมบูรณ์และไม่มีสิ่งที่น่าสนใจที่จะช่วยให้เราทำงานกับฐานข้อมูลได้ดีขึ้น ดังนั้นการตรวจสอบจึงต้องทำให้เสร็จสิ้นเสมอ

ฐานข้อมูลเป็นสิ่งที่ซับซ้อนซึ่งจำเป็นต้องได้รับการตรวจสอบด้วย เนื่องจากฐานข้อมูลเป็นแหล่งเก็บข้อมูล และข้อมูลมีความสำคัญมากสำหรับบริษัทไม่สูญหายแต่อย่างใด แต่ในขณะเดียวกัน ฐานข้อมูลก็เป็นซอฟต์แวร์ที่ซับซ้อนมาก ประกอบด้วยส่วนประกอบจำนวนมาก และองค์ประกอบหลายอย่างเหล่านี้จำเป็นต้องได้รับการตรวจสอบ

หากเรากำลังพูดถึง PostgreSQL โดยเฉพาะก็สามารถแสดงในรูปแบบของโครงร่างที่ประกอบด้วยส่วนประกอบจำนวนมาก ส่วนประกอบเหล่านี้มีปฏิสัมพันธ์ซึ่งกันและกัน และในเวลาเดียวกัน PostgreSQL ก็มีระบบย่อยที่เรียกว่า Stats Collector ซึ่งช่วยให้คุณสามารถรวบรวมสถิติเกี่ยวกับการทำงานของระบบย่อยเหล่านี้และจัดเตรียมอินเทอร์เฟซบางอย่างให้กับผู้ดูแลระบบหรือผู้ใช้เพื่อให้เขาสามารถดูสถิติเหล่านี้ได้

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

คุณสามารถเพิ่มตัวเลขเหล่านี้ลงในระบบการตรวจสอบที่คุณชื่นชอบ วาดกราฟ เพิ่มฟังก์ชัน และรับการวิเคราะห์ในระยะยาว

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

และถ้าเราพูดถึง Database Monitoring จะต้อง Monitor อะไรบ้าง? ก่อนอื่น เราต้องตรวจสอบความพร้อมใช้งาน เนื่องจากฐานข้อมูลเป็นบริการที่ให้การเข้าถึงข้อมูลแก่ลูกค้า และเราจำเป็นต้องตรวจสอบความพร้อมใช้งาน และยังให้คุณลักษณะเชิงคุณภาพและเชิงปริมาณบางประการด้วย

นอกจากนี้เรายังจำเป็นต้องตรวจสอบไคลเอนต์ที่เชื่อมต่อกับฐานข้อมูลของเรา เนื่องจากอาจเป็นทั้งไคลเอนต์ปกติและไคลเอนต์ที่เป็นอันตรายที่อาจเป็นอันตรายต่อฐานข้อมูล พวกเขายังต้องได้รับการตรวจสอบและติดตามกิจกรรมของพวกเขาด้วย

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

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

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

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

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

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

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

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

คุณควรเพิ่มอะไรลงในแดชบอร์ดเหล่านี้ คุณสามารถเริ่มต้นด้วยคุณลักษณะเช่นเวลาตอบสนอง PostgreSQL มีมุมมอง pg_stat_statements มันถูกปิดใช้งานโดยค่าเริ่มต้น แต่เป็นหนึ่งในมุมมองระบบที่สำคัญที่ควรเปิดใช้งานและใช้งานเสมอ มันเก็บข้อมูลเกี่ยวกับการสืบค้นที่ทำงานอยู่ทั้งหมดซึ่งได้รับการดำเนินการในฐานข้อมูล

ดังนั้นเราจึงสามารถเริ่มต้นจากข้อเท็จจริงที่ว่าเราสามารถนำเวลาดำเนินการทั้งหมดของคำขอทั้งหมดมาหารด้วยจำนวนคำขอโดยใช้ช่องด้านบน แต่นี่คืออุณหภูมิเฉลี่ยในโรงพยาบาล เราสามารถเริ่มจากฟิลด์อื่นๆ ได้ - เวลาดำเนินการแบบสอบถามขั้นต่ำ, สูงสุดและค่ามัธยฐาน และเรายังสามารถสร้างเปอร์เซ็นไทล์ได้ PostgreSQL มีฟังก์ชันที่เกี่ยวข้องสำหรับสิ่งนี้ และเราจะได้รับตัวเลขบางตัวที่ระบุลักษณะเวลาตอบสนองของฐานข้อมูลของเราสำหรับคำขอที่เสร็จสมบูรณ์แล้ว เช่น เราไม่ได้ดำเนินการคำขอปลอม 'เลือก 1' และดูเวลาตอบสนอง แต่เราวิเคราะห์เวลาตอบสนองสำหรับคำขอและการจับรางวัลที่เสร็จสมบูรณ์แล้ว อาจเป็นตัวเลขที่แยกจากกัน หรือเราสร้างกราฟจากตัวเลขนั้น

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

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

ในการประมาณจำนวนธุรกรรม เราสามารถอ้างอิงถึงมุมมอง pg_stat_database ได้อีกครั้ง เราสามารถเพิ่มจำนวนการคอมมิตและจำนวนการย้อนกลับและรับจำนวนธุรกรรมต่อวินาที

ทุกคนเข้าใจหรือไม่ว่าคำขอหลายรายการสามารถรวมอยู่ในธุรกรรมเดียวได้ ดังนั้น TPS และ QPS จึงแตกต่างกันเล็กน้อย

จำนวนคำขอต่อวินาทีสามารถรับได้จาก pg_stat_statements และคำนวณผลรวมของคำขอที่เสร็จสมบูรณ์ทั้งหมด เห็นได้ชัดว่าเราเปรียบเทียบค่าปัจจุบันกับค่าก่อนหน้า ลบออก รับเดลต้า และรับปริมาณ

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

หนึ่งในตัวชี้วัดเหล่านี้คือสถานะการออนไลน์ แต่สถานะการออนไลน์ใน PostgreSQL นั้นค่อนข้างยุ่งยากเล็กน้อย ฉันจะบอกคุณว่าทำไม เมื่อ PostgreSQL เริ่มต้นแล้ว เวลาทำงานจะเริ่มการรายงาน แต่หาก ณ จุดใดจุดหนึ่ง เช่น มีงานบางอย่างทำงานในเวลากลางคืน OOM-killer ก็เข้ามาและบังคับให้ยุติกระบวนการย่อยของ PostgreSQL จากนั้นในกรณีนี้ PostgreSQL จะยุติการเชื่อมต่อของไคลเอ็นต์ทั้งหมด รีเซ็ตพื้นที่หน่วยความจำที่แบ่งส่วน และเริ่มการกู้คืนจาก ด่านสุดท้าย และในขณะที่การกู้คืนจากจุดตรวจสอบนี้ยังคงอยู่ ฐานข้อมูลจะไม่ยอมรับการเชื่อมต่อ กล่าวคือ สถานการณ์นี้สามารถประเมินได้ว่าเป็นการหยุดทำงาน แต่ตัวนับเวลาทำงานจะไม่ถูกรีเซ็ตเนื่องจากจะคำนึงถึงเวลาเริ่มต้นของ postmaster ตั้งแต่วินาทีแรก ดังนั้นจึงสามารถข้ามสถานการณ์ดังกล่าวได้

คุณควรตรวจสอบจำนวนพนักงานดูดฝุ่นด้วย ทุกคนรู้หรือไม่ว่า autovacuum ใน PostgreSQL คืออะไร? นี่เป็นระบบย่อยที่น่าสนใจใน PostgreSQL มีการเขียนบทความเกี่ยวกับเธอมากมายและมีรายงานมากมาย มีการพูดคุยกันมากมายเกี่ยวกับสุญญากาศและควรทำงานอย่างไร หลายคนคิดว่ามันเป็นสิ่งชั่วร้ายที่จำเป็น แต่มันก็เป็นเช่นนั้น นี่คืออะนาล็อกชนิดหนึ่งของตัวรวบรวมขยะที่จะล้างแถวเวอร์ชันเก่าที่ไม่จำเป็นสำหรับธุรกรรมใด ๆ และเพิ่มพื้นที่ว่างในตารางและดัชนีสำหรับแถวใหม่

ทำไมคุณต้องติดตามมัน? เพราะบางครั้งเครื่องดูดฝุ่นก็เจ็บมาก ใช้ทรัพยากรจำนวนมากและคำขอของลูกค้าก็เริ่มได้รับผลกระทบ

และควรได้รับการตรวจสอบผ่านมุมมอง pg_stat_activity ซึ่งฉันจะพูดถึงในส่วนถัดไป มุมมองนี้แสดงกิจกรรมปัจจุบันในฐานข้อมูล และจากกิจกรรมนี้ เราสามารถติดตามจำนวนเครื่องดูดฝุ่นที่ทำงานอยู่ในขณะนี้ได้ เราสามารถติดตามสุญญากาศและดูว่าหากเราเกินขีดจำกัดแล้ว นี่เป็นเหตุผลที่ต้องพิจารณาการตั้งค่า PostgreSQL และเพิ่มประสิทธิภาพการทำงานของสุญญากาศ

อีกสิ่งหนึ่งที่เกี่ยวกับ PostgreSQL ก็คือ PostgreSQL เบื่อหน่ายกับการทำธุรกรรมที่ยาวนาน โดยเฉพาะจากธุรกรรมที่ค้างอยู่นานและไม่ทำอะไรเลย นี่คือสิ่งที่เรียกว่าสถิติที่ไม่ได้ใช้งานในการทำธุรกรรม ธุรกรรมดังกล่าวจะล็อคและป้องกันไม่ให้สุญญากาศทำงาน และเป็นผลให้โต๊ะขยายตัวและมีขนาดเพิ่มขึ้น และการสืบค้นที่ทำงานกับตารางเหล่านี้จะเริ่มทำงานช้าลง เนื่องจากคุณจำเป็นต้องย้ายแถวเวอร์ชันเก่าทั้งหมดจากหน่วยความจำไปยังดิสก์และด้านหลัง ดังนั้นจึงต้องตรวจสอบเวลา ระยะเวลาของธุรกรรมที่ยาวที่สุด และคำขอสุญญากาศที่ยาวที่สุดด้วย และหากเราเห็นกระบวนการบางอย่างที่ทำงานมาเป็นเวลานานมากเกินกว่า 10-20-30 นาทีแล้วสำหรับโหลด OLTP แล้ว เราจำเป็นต้องให้ความสนใจกับกระบวนการเหล่านั้นและยุติกระบวนการเหล่านั้นอย่างแข็งขัน หรือปรับแอปพลิเคชันให้เหมาะสมที่สุด ไม่ถูกเรียกและอย่าวางสายนานนัก สำหรับปริมาณงานเชิงวิเคราะห์ 10-20-30 นาทีเป็นเรื่องปกติ และยังมีงานที่นานกว่านั้นด้วย

ต่อไปเรามีตัวเลือกกับไคลเอนต์ที่เชื่อมต่อ เมื่อเราสร้างแดชบอร์ดและโพสต์การวัดความพร้อมใช้งานที่สำคัญแล้ว เรายังสามารถเพิ่มข้อมูลเพิ่มเติมเกี่ยวกับไคลเอนต์ที่เชื่อมต่อได้ที่นั่นด้วย

ข้อมูลเกี่ยวกับไคลเอนต์ที่เชื่อมต่อเป็นสิ่งสำคัญ เนื่องจากจากมุมมองของ PostgreSQL ไคลเอนต์นั้นแตกต่างกัน มีลูกค้าที่ดีและมีลูกค้าที่ไม่ดี

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

มีบางสถานการณ์ที่ไคลเอนต์เชื่อมต่ออยู่ โดยจะคงการเชื่อมต่อไว้แต่ไม่ได้ทำอะไรเลย มันอยู่ในสถานะไม่ได้ใช้งาน

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

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

อีกตัวอย่างหนึ่งของการติดตาม และมีแดชบอร์ดที่เหมาะสมอยู่แล้วที่นี่ มีข้อมูลเกี่ยวกับการเชื่อมต่อข้างต้น การเชื่อมต่อฐานข้อมูล – 8 ชิ้น และนั่นคือทั้งหมด เราไม่มีข้อมูลเกี่ยวกับลูกค้ารายใดที่ใช้งานอยู่ ลูกค้ารายใดเพียงไม่ได้ใช้งานและไม่ได้ทำอะไรเลย ไม่มีข้อมูลเกี่ยวกับธุรกรรมที่รอดำเนินการและการเชื่อมต่อที่รอดำเนินการ เช่น นี่คือตัวเลขที่แสดงจำนวนการเชื่อมต่อก็แค่นั้นแหละ แล้วเดาเอาเองว่า

ดังนั้น ในการเพิ่มข้อมูลนี้ในการมอนิเตอร์ คุณต้องเข้าถึงมุมมองระบบ pg_stat_activity หากคุณใช้เวลาส่วนใหญ่ใน PostgreSQL นี่เป็นมุมมองที่ดีมากที่ควรเป็นเพื่อนของคุณ เพราะมันจะแสดงกิจกรรมปัจจุบันใน PostgreSQL เช่น สิ่งที่เกิดขึ้นในนั้น สำหรับแต่ละกระบวนการจะมีบรรทัดแยกต่างหากที่แสดงข้อมูลเกี่ยวกับกระบวนการนี้: การเชื่อมต่อเกิดขึ้นจากโฮสต์ใด ภายใต้ผู้ใช้ใด ภายใต้ชื่อใด ธุรกรรมเริ่มต้นเมื่อใด คำขอใดที่กำลังทำงานอยู่ คำขอใดที่ดำเนินการครั้งล่าสุด และด้วยเหตุนี้ เราจึงสามารถประเมินสถานะของลูกค้าได้โดยใช้ช่องสถิติ ในทางกลับกัน เราสามารถจัดกลุ่มตามฟิลด์นี้และรับสถิติที่มีอยู่ในฐานข้อมูลในปัจจุบันและจำนวนการเชื่อมต่อที่มีสถิตินี้ในฐานข้อมูล และเราสามารถส่งตัวเลขที่ได้รับแล้วไปยังการตรวจสอบและวาดกราฟตามตัวเลขเหล่านั้นได้
การประเมินระยะเวลาของธุรกรรมเป็นสิ่งสำคัญเช่นกัน ฉันได้กล่าวไปแล้วว่าการประเมินระยะเวลาของสุญญากาศเป็นสิ่งสำคัญ แต่ธุรกรรมจะได้รับการประเมินในลักษณะเดียวกัน มีฟิลด์ xact_start และ query_start พูดค่อนข้างชัดคือแสดงเวลาเริ่มต้นของธุรกรรมและเวลาเริ่มต้นของคำขอ เราใช้ฟังก์ชัน now() ซึ่งแสดงการประทับเวลาปัจจุบัน และลบธุรกรรมและการประทับเวลาของคำขอ และเราได้ระยะเวลาของการทำธุรกรรม ระยะเวลาของคำขอ

หากเราเห็นธุรกรรมยาวเราควรดำเนินการให้เสร็จสิ้นแล้ว สำหรับการโหลด OLTP ธุรกรรมที่ยาวนานจะใช้เวลามากกว่า 1-2-3 นาทีแล้ว. สำหรับปริมาณงาน OLAP ธุรกรรมที่ยาวนานถือเป็นเรื่องปกติ แต่หากใช้เวลานานกว่าสองชั่วโมงในการดำเนินการให้เสร็จสิ้น นี่ก็เป็นสัญญาณว่าเรามีความคลาดเคลื่อนอยู่บ้าง

เมื่อลูกค้าเชื่อมต่อกับฐานข้อมูลแล้ว พวกเขาก็จะเริ่มทำงานกับข้อมูลของเรา พวกเขาเข้าถึงตาราง พวกเขาเข้าถึงดัชนีเพื่อรับข้อมูลจากตาราง และสิ่งสำคัญคือต้องประเมินว่าลูกค้าโต้ตอบกับข้อมูลนี้อย่างไร

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

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

คุณยังสามารถตรวจจับความผิดปกติได้ในสถิติ "ลอยตัว" มันหมายความว่าอะไร? PostgreSQL มีตัวกำหนดเวลาคิวรีที่แข็งแกร่งและดีมาก และนักพัฒนาก็ทุ่มเทเวลาอย่างมากในการพัฒนา เขาทำงานยังไงบ้าง? เพื่อที่จะวางแผนที่ดี PostgreSQL จะรวบรวมสถิติเกี่ยวกับการกระจายข้อมูลในตารางในช่วงเวลาหนึ่งและด้วยความถี่ที่แน่นอน ค่าเหล่านี้เป็นค่าที่พบบ่อยที่สุด ได้แก่ จำนวนค่าที่ไม่ซ้ำ ข้อมูลเกี่ยวกับ NULL ในตาราง ข้อมูลจำนวนมาก

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

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

และเราสามารถเห็นสิ่งนี้ได้ในการติดตาม และดูคำค้นหานี้แล้ว เรียกใช้คำอธิบาย รวบรวมสถิติ สร้างดัชนีเพิ่มเติมใหม่ และตอบสนองต่อปัญหานี้แล้ว นั่นเป็นเหตุผลว่าทำไมมันถึงสำคัญ

อีกตัวอย่างหนึ่งของการติดตาม ฉันคิดว่าหลายคนจำเขาได้เพราะเขาดังมาก ใครใช้ในโครงการของตน โพร? ใครใช้ผลิตภัณฑ์นี้ร่วมกับ Prometheus? ความจริงก็คือในพื้นที่เก็บข้อมูลมาตรฐานของการตรวจสอบนี้มีแดชบอร์ดสำหรับการทำงานกับ PostgreSQL - postgres_exporter โพรมีธีอุส แต่มีรายละเอียดที่ไม่ดีอย่างหนึ่ง

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

จะรับสถิติในตารางเหล่านี้ได้อย่างไร? เพื่อจุดประสงค์นี้ PostgreSQL จึงมีกลุ่มมุมมองที่แน่นอน และมุมมองหลักก็คือ pg_stat_user_tables. User_tables - หมายถึงตารางที่สร้างขึ้นในนามของผู้ใช้ ในทางตรงกันข้าม มีมุมมองของระบบที่ PostgreSQL ใช้เอง และมีตารางสรุป Alltables ซึ่งมีทั้งระบบและผู้ใช้ คุณสามารถเริ่มต้นจากสิ่งที่คุณชอบที่สุด

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

จากข้อมูลนี้ เราสามารถสร้างสิ่งที่เรียกว่าตาราง TopN ได้ ตัวอย่างเช่น Top-5, Top-10 และคุณสามารถติดตามโต๊ะร้อนๆ ที่ถูกรีไซเคิลได้มากกว่าโต๊ะอื่น ตัวอย่างเช่น 5 ตาราง "ร้อน" สำหรับการแทรก และการใช้ตาราง TopN เหล่านี้ทำให้เราประเมินปริมาณงานของเราและสามารถประเมินปริมาณงานที่เพิ่มขึ้นหลังจากการเผยแพร่ การอัปเดต และการปรับใช้ใดๆ

การประเมินขนาดของตารางก็เป็นสิ่งสำคัญเช่นกัน เนื่องจากบางครั้งนักพัฒนาซอฟต์แวร์ก็ออกฟีเจอร์ใหม่ และตารางของเราก็เริ่มมีขนาดใหญ่ขึ้น เพราะพวกเขาตัดสินใจเพิ่มข้อมูลเพิ่มเติม แต่ไม่ได้คาดการณ์ว่าจะเป็นอย่างไร ส่งผลต่อขนาดของฐานข้อมูล กรณีเช่นนี้ทำให้เราประหลาดใจเช่นกัน

และตอนนี้คำถามเล็ก ๆ สำหรับคุณ คำถามอะไรจะเกิดขึ้นเมื่อคุณสังเกตเห็นภาระงานบนเซิร์ฟเวอร์ฐานข้อมูลของคุณ คุณมีคำถามอะไรต่อไป?

แต่ในความเป็นจริงคำถามก็เกิดขึ้นดังนี้ คำขอใดที่ทำให้เกิดการโหลด นั่นคือมันไม่น่าสนใจที่จะดูกระบวนการที่เกิดจากโหลด เป็นที่ชัดเจนว่าหากโฮสต์มีฐานข้อมูล แสดงว่าฐานข้อมูลกำลังทำงานอยู่ที่นั่น และเป็นที่ชัดเจนว่าจะมีเพียงฐานข้อมูลเท่านั้นที่จะถูกกำจัดทิ้งที่นั่น ถ้าเราเปิด Top เราจะเห็นรายการกระบวนการใน PostgreSQL ที่กำลังทำอะไรบางอย่างอยู่ ท็อปจะไม่ชัดเจนว่าพวกเขากำลังทำอะไรอยู่

ดังนั้น คุณต้องค้นหาคำค้นหาที่ทำให้เกิดภาระงานสูงสุด เนื่องจากตามกฎแล้ว การปรับแต่งการสืบค้นจะให้ผลกำไรมากกว่าการปรับแต่ง PostgreSQL หรือการกำหนดค่าระบบปฏิบัติการ หรือแม้แต่การปรับแต่งฮาร์ดแวร์ ตามการประมาณการของฉันนี่คือประมาณ 80-85-90% และทำได้เร็วกว่ามาก การแก้ไขคำขอทำได้เร็วกว่าการแก้ไขการกำหนดค่า กำหนดเวลาการรีสตาร์ท โดยเฉพาะอย่างยิ่งหากฐานข้อมูลไม่สามารถรีสตาร์ทได้ หรือเพิ่มฮาร์ดแวร์ ง่ายกว่าที่จะเขียนแบบสอบถามใหม่หรือเพิ่มดัชนีเพื่อให้ได้ผลลัพธ์ที่ดีขึ้นจากแบบสอบถามนี้

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

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

คุณสามารถตรวจสอบการสืบค้นที่ยาวที่สุดได้ นั่นคือ การสืบค้นที่ใช้เวลานานที่สุดในการดำเนินการให้เสร็จสิ้น พวกเขาทำงานบนโปรเซสเซอร์ พวกเขาใช้ I/O นอกจากนี้เรายังสามารถประเมินสิ่งนี้ได้โดยใช้ฟิลด์ Total_time, Mean_time, blk_write_time และ blk_read_time

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

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

และคุณยังสามารถติดตามการสืบค้นที่ใช้ไฟล์ชั่วคราวหรือตารางชั่วคราวได้อีกด้วย

และเรายังมีกระบวนการเบื้องหลังอยู่ กระบวนการเบื้องหลังเป็นจุดตรวจเป็นหลักหรือเรียกอีกอย่างว่าจุดตรวจสอบ ซึ่งก็คือจุดตรวจสูญญากาศอัตโนมัติและการจำลองแบบ

อีกตัวอย่างหนึ่งของการติดตาม มีแท็บการบำรุงรักษาทางด้านซ้าย เข้าไปแล้วหวังว่าจะเห็นสิ่งที่มีประโยชน์ แต่นี่เป็นเพียงช่วงเวลาของการดำเนินการสุญญากาศและการเก็บสถิติเท่านั้น ไม่มีอะไรเพิ่มเติม นี่เป็นข้อมูลที่แย่มาก ดังนั้นเราจึงจำเป็นต้องมีข้อมูลเสมอเกี่ยวกับวิธีการทำงานของกระบวนการเบื้องหลังในฐานข้อมูลของเรา และไม่ว่าจะมีปัญหาใดๆ จากการทำงานหรือไม่

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

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

ดังนั้น ผ่าน pg_stat_bgwriter โดยใช้ฟิลด์ที่ระบุ เราจึงสามารถตรวจสอบจำนวนจุดตรวจสอบที่เกิดขึ้นได้ และถ้าเรามีจุดตรวจจำนวนมากในช่วงเวลาหนึ่ง (ใน 10-15-20 นาที, ในครึ่งชั่วโมง) เช่น 3-4-5 นี่ก็อาจเป็นปัญหาได้แล้ว และคุณต้องดูในฐานข้อมูลแล้วดูในการกำหนดค่าว่าอะไรเป็นสาเหตุของจุดตรวจมากมาย อาจจะมีการบันทึกครั้งใหญ่เกิดขึ้น เราสามารถประเมินปริมาณงานได้แล้ว เนื่องจากเราได้เพิ่มกราฟปริมาณงานแล้ว เราสามารถปรับแต่งพารามิเตอร์จุดตรวจได้แล้ว และตรวจสอบให้แน่ใจว่าพารามิเตอร์เหล่านั้นไม่ส่งผลกระทบอย่างมากต่อประสิทธิภาพการค้นหา

ฉันกลับมาที่ Autovacuum อีกครั้ง เพราะมันเป็นสิ่งที่สามารถเพิ่มทั้งประสิทธิภาพดิสก์และการสืบค้นได้อย่างง่ายดาย ดังนั้นจึงเป็นเรื่องสำคัญเสมอที่จะประมาณปริมาณของ Autovacuum

จำนวนพนักงาน autovacuum ในฐานข้อมูลมีจำนวนจำกัด ตามค่าเริ่มต้น มีสามคน ดังนั้นหากเรามีพนักงานสามคนทำงานในฐานข้อมูลเสมอ นั่นหมายความว่าไม่ได้กำหนดค่า autovacuum ของเรา เราจำเป็นต้องเพิ่มขีดจำกัด แก้ไขการตั้งค่า autovacuum และเข้าสู่การกำหนดค่า
สิ่งสำคัญคือต้องประเมินว่าเรามีพนักงานดูดฝุ่นคนไหน ไม่ว่าจะเปิดตัวจากผู้ใช้ DBA ก็มาและเปิดตัวสุญญากาศบางประเภทด้วยตนเอง และสิ่งนี้ทำให้เกิดภาระ เรามีปัญหาบางอย่าง หรือนี่คือจำนวนเครื่องดูดฝุ่นที่คลายเกลียวตัวนับธุรกรรม สำหรับ PostgreSQL บางเวอร์ชัน สิ่งเหล่านี้ถือเป็นสุญญากาศที่หนักมาก และพวกเขาสามารถเพิ่มประสิทธิภาพได้อย่างง่ายดายเพราะพวกเขาอ่านทั้งตาราง สแกนบล็อคทั้งหมดในตารางนั้น

และแน่นอนว่าระยะเวลาในการดูดฝุ่นด้วย หากเรามีเครื่องดูดฝุ่นที่มีอายุการใช้งานยาวนานซึ่งทำงานเป็นเวลานาน นั่นหมายความว่าเราต้องให้ความสนใจกับการกำหนดค่าเครื่องดูดฝุ่นอีกครั้ง และอาจพิจารณาการตั้งค่าอีกครั้ง เนื่องจากสถานการณ์อาจเกิดขึ้นเมื่อเครื่องดูดฝุ่นทำงานบนโต๊ะเป็นเวลานาน (3-4 ชั่วโมง) แต่ในระหว่างที่สูญญากาศทำงานอยู่ แถวที่ตายแล้วจำนวนมากก็สามารถสะสมอยู่ในโต๊ะได้อีกครั้ง และทันทีที่ดูดฝุ่นเสร็จ เขาก็ต้องดูดโต๊ะนี้อีกครั้ง และเราก็มาถึงสถานการณ์ - สุญญากาศอันไม่มีที่สิ้นสุด และในกรณีนี้สุญญากาศไม่สามารถรับมือกับงานของมันได้และตารางก็เริ่มมีขนาดเพิ่มขึ้นเรื่อย ๆ แม้ว่าปริมาณข้อมูลที่เป็นประโยชน์ในนั้นจะยังคงเท่าเดิมก็ตาม ดังนั้น ในระหว่างการสุญญากาศที่ยาวนาน เรามักจะดูการกำหนดค่าอยู่เสมอและพยายามปรับให้เหมาะสม แต่ในขณะเดียวกัน เพื่อไม่ให้ประสิทธิภาพของคำขอของไคลเอนต์ได้รับผลกระทบ

ปัจจุบันไม่มีการติดตั้ง PostgreSQL ใดที่ไม่มีการจำลองแบบสตรีมมิ่ง การจำลองแบบคือกระบวนการย้ายข้อมูลจากต้นแบบไปยังแบบจำลอง

การจำลองแบบใน PostgreSQL ทำได้ผ่านบันทึกธุรกรรม ตัวช่วยสร้างสร้างบันทึกธุรกรรม บันทึกธุรกรรมเดินทางผ่านการเชื่อมต่อเครือข่ายไปยังแบบจำลอง และจากนั้น จะทำซ้ำบนแบบจำลอง มันง่ายมาก

ดังนั้น มุมมอง pg_stat_replication จึงถูกใช้เพื่อมอนิเตอร์ความล่าช้าในการจำลอง แต่ไม่ใช่ทุกอย่างจะง่ายสำหรับเธอ ในเวอร์ชัน 10 มุมมองมีการเปลี่ยนแปลงหลายประการ ประการแรก บางฟิลด์ได้ถูกเปลี่ยนชื่อแล้ว และมีการเพิ่มบางช่องแล้ว ในเวอร์ชัน 10 ฟิลด์ปรากฏขึ้นเพื่อให้คุณสามารถประมาณความล่าช้าในการจำลองได้ในไม่กี่วินาที มันสะดวกสบายมาก ก่อนเวอร์ชัน 10 สามารถประมาณความล่าช้าในการจำลองข้อมูลเป็นไบต์ได้ ตัวเลือกนี้ยังคงอยู่ในเวอร์ชัน 10 เช่น คุณสามารถเลือกสิ่งที่สะดวกกว่าสำหรับคุณ - ประเมินความล่าช้าเป็นไบต์หรือประมาณความล่าช้าเป็นวินาที หลายคนทำทั้งสองอย่าง

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

ในเวอร์ชัน 10 ฟังก์ชันนี้ถูกเปลี่ยนชื่อเป็น pg_wal_lsn_diff() โดยทั่วไป ในทุกฟังก์ชัน มุมมอง และยูทิลิตี้ที่มีคำว่า "xlog" ปรากฏ คำว่า "xlog" ปรากฏขึ้น จะถูกแทนที่ด้วยค่า "wal" สิ่งนี้ใช้ได้กับทั้งมุมมองและฟังก์ชัน นี่เป็นนวัตกรรมเช่นนี้

นอกจากนี้ในเวอร์ชัน 10 มีการเพิ่มบรรทัดที่แสดงความล่าช้าโดยเฉพาะ เหล่านี้คือความล่าช้าในการเขียน, ความล่าช้าแบบฟลัช, ความล่าช้าในการเล่นซ้ำ นั่นคือสิ่งสำคัญคือต้องติดตามสิ่งเหล่านี้ หากเราเห็นว่าเรามีความล่าช้าในการจำลอง เราต้องตรวจสอบว่าเหตุใดจึงปรากฏขึ้น มาจากไหน และแก้ไขปัญหา

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

หากทุกอย่างเป็นไปตามกระบวนการรีไซเคิล แสดงว่ามีปัญหากับการรีไซเคิลดิสก์ ตามกฎแล้ว การตรวจสอบนักพัฒนาจะเพิ่มข้อมูลเกี่ยวกับปริมาณงาน อาจเป็นหน่วย iops หรือไบต์ก็ได้ แต่พวกเขาลืมเกี่ยวกับเวลาแฝงและการใช้งานอุปกรณ์ดิสก์ เหล่านี้เป็นพารามิเตอร์ที่สำคัญกว่าซึ่งช่วยให้เราสามารถประเมินได้ว่าดิสก์ของเราโหลดแค่ไหนและช้าแค่ไหน หากเรามีเวลาแฝงสูงแสดงว่ามีปัญหากับดิสก์ หากเรามีการใช้งานสูง แสดงว่าดิสก์ไม่สามารถรองรับได้ สิ่งเหล่านี้เป็นคุณลักษณะที่ดีกว่าปริมาณงาน

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

เช่นเดียวกับอินเทอร์เฟซเครือข่าย มีข้อมูลเกี่ยวกับปริมาณงานของเครือข่ายเป็นแพ็กเก็ต หน่วยเป็นไบต์ แต่ไม่มีข้อมูลเกี่ยวกับเวลาแฝงและไม่มีข้อมูลเกี่ยวกับการใช้งาน แม้ว่านี่จะเป็นข้อมูลที่เป็นประโยชน์ก็ตาม

การตรวจสอบใด ๆ ก็มีข้อเสีย และไม่ว่าคุณจะทำการตรวจสอบแบบใด มันก็จะไม่เป็นไปตามเกณฑ์บางประการเสมอไป แต่อย่างไรก็ตาม พวกเขากำลังพัฒนา มีการเพิ่มฟีเจอร์ใหม่และสิ่งใหม่ๆ ดังนั้นเลือกบางอย่างแล้วทำให้เสร็จ

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

และประเด็นสำคัญบางประการ:

• คุณควรตรวจสอบความพร้อมใช้งานและมีแดชบอร์ดอยู่เสมอ เพื่อให้คุณสามารถประเมินได้อย่างรวดเร็วว่าทุกอย่างเป็นไปตามลำดับของฐานข้อมูล
• คุณต้องมีความคิดอยู่เสมอว่าลูกค้ารายใดทำงานกับฐานข้อมูลของคุณเพื่อกำจัดลูกค้าที่ไม่ดีและกำจัดพวกเขาทิ้ง
• สิ่งสำคัญคือต้องประเมินว่าไคลเอ็นต์เหล่านี้ทำงานกับข้อมูลอย่างไร คุณต้องมีความคิดเกี่ยวกับภาระงานของคุณ
• สิ่งสำคัญคือต้องประเมินว่าเวิร์กโหลดนี้เกิดขึ้นได้อย่างไร โดยอาศัยความช่วยเหลือจากคำถามใด คุณสามารถประเมินคำค้นหา คุณสามารถปรับให้เหมาะสม ปรับโครงสร้างใหม่ สร้างดัชนีสำหรับคำค้นหาเหล่านั้นได้ มันสำคัญมาก.
• กระบวนการเบื้องหลังอาจส่งผลเสียต่อคำขอของลูกค้าได้ ดังนั้นการตรวจสอบว่าพวกเขาไม่ได้ใช้ทรัพยากรมากเกินไปจึงเป็นสิ่งสำคัญ
• หน่วยเมตริกระบบช่วยให้คุณสามารถวางแผนการปรับขนาดและเพิ่มความจุของเซิร์ฟเวอร์ได้ การติดตามและประเมินผลก็เป็นสิ่งสำคัญเช่นกัน

หากคุณสนใจหัวข้อนี้คุณสามารถติดตามลิงก์เหล่านี้ได้
http://bit.do/stats_collector - นี่คือเอกสารอย่างเป็นทางการจากนักสะสมสถิติ มีคำอธิบายมุมมองทางสถิติทั้งหมดและคำอธิบายทุกสาขา คุณสามารถอ่าน ทำความเข้าใจ และวิเคราะห์ได้ และสร้างกราฟของคุณและเพิ่มลงในการติดตามของคุณโดยอิงจากกราฟเหล่านั้น

คำขอตัวอย่าง:
http://bit.do/dataegret_sql
http://bit.do/lesovsky_sql

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

คำถาม

คำถาม: คุณบอกว่าจะไม่โฆษณาแบรนด์ แต่ฉันยังสงสัยว่าคุณใช้แดชบอร์ดประเภทใดในโครงการของคุณ
คำตอบ: มันแตกต่างกันไป มันเกิดขึ้นที่เราไปหาลูกค้าและเขาก็มีการติดตามของเขาอยู่แล้ว และเราแนะนำลูกค้าเกี่ยวกับสิ่งที่จำเป็นต้องเพิ่มในการติดตามของพวกเขา สถานการณ์ที่เลวร้ายที่สุดคือกับ Zabbix เนื่องจากไม่มีความสามารถในการสร้างกราฟ TopN เราเองใช้ โอเคมิเตอร์เนื่องจากเราได้ปรึกษากับคนเหล่านี้ในการติดตาม พวกเขาตรวจสอบ PostgreSQL ตามข้อกำหนดทางเทคนิคของเรา ฉันกำลังเขียนโปรเจ็กต์สัตว์เลี้ยงของตัวเอง ซึ่งรวบรวมข้อมูลผ่าน Prometheus และแสดงผล กราฟาน่า. งานของฉันคือสร้างผู้ส่งออกของตัวเองใน Prometheus จากนั้นเรนเดอร์ทุกอย่างใน Grafana

คำถาม: มีรายงาน AWR หรือ... การรวมกลุ่มที่คล้ายคลึงกันหรือไม่ คุณรู้เกี่ยวกับสิ่งนี้หรือไม่?
คำตอบ: ใช่ ฉันรู้ว่า AWR คืออะไร มันเจ๋งมาก ในขณะนี้มีจักรยานหลายประเภทที่ใช้ประมาณรุ่นต่อไปนี้ ในช่วงเวลาหนึ่ง เส้นพื้นฐานบางส่วนจะถูกเขียนไปยัง PostgreSQL เดียวกันหรือพื้นที่จัดเก็บแยกต่างหาก คุณสามารถ google บนอินเทอร์เน็ตได้ พวกมันอยู่ที่นั่น หนึ่งในนักพัฒนาของสิ่งนี้กำลังนั่งอยู่ในฟอรัม sql.ru ในเธรด PostgreSQL คุณสามารถจับเขาได้ที่นั่น ใช่มีของแบบนั้นก็สามารถใช้ได้ บวกกับมัน pgCenter ฉันยังเขียนสิ่งที่ช่วยให้คุณทำสิ่งเดียวกันได้

PS1 หากคุณใช้ postgres_exporter คุณใช้แดชบอร์ดใด มีหลายคน พวกเขาล้าสมัยไปแล้ว บางทีชุมชนอาจจะสร้างเทมเพลตที่อัปเดตแล้ว?

PS2 ลบ pganalyze เนื่องจากเป็นข้อเสนอ SaaS ที่เป็นกรรมสิทธิ์ ซึ่งมุ่งเน้นไปที่การตรวจสอบประสิทธิภาพและคำแนะนำในการปรับแต่งอัตโนมัติ

เฉพาะผู้ใช้ที่ลงทะเบียนเท่านั้นที่สามารถเข้าร่วมในการสำรวจได้ เข้าสู่ระบบ, โปรด.

การตรวจสอบ postgresql ที่โฮสต์เอง (พร้อมแดชบอร์ด) ใดที่คุณคิดว่าดีที่สุด

• ลด 30,0%Zabbix + ส่วนเพิ่มเติมจาก Alexey Lesovsky หรือ zabbix 4.4 หรือ libzbxpgsql + zabbix libzbxpgsql + zabbix3

• ลด 0,0%https://github.com/lesovsky/pgcenter0

• ลด 0,0%https://github.com/pg-monz/pg_monz0

• ลด 20,0%https://github.com/cybertec-postgresql/pgwatch22

• ลด 20,0%https://github.com/postgrespro/mamonsu2

• ลด 0,0%https://www.percona.com/doc/percona-monitoring-and-management/conf-postgres.html0

• ลด 10,0%pganalyze เป็น SaaS ที่เป็นกรรมสิทธิ์ - ฉันไม่สามารถลบมันได้1

• ลด 10,0%https://github.com/powa-team/powa1

• ลด 0,0%https://github.com/darold/pgbadger0

• ลด 0,0%https://github.com/darold/pgcluu0

• ลด 0,0%https://github.com/zalando/PGObserver0

• ลด 10,0%https://github.com/spotify/postgresql-metrics1

ผู้ใช้ 10 คนโหวต ผู้ใช้ 26 รายงดออกเสียง

ที่มา: will.com