ประสิทธิภาพสูงและการแบ่งพาร์ติชันดั้งเดิม: Zabbix พร้อมรองรับ TimescaleDB

Zabbix เป็นระบบตรวจสอบ เช่นเดียวกับระบบอื่นๆ มันประสบปัญหาหลักสามประการของระบบตรวจสอบทั้งหมด: การรวบรวมและประมวลผลข้อมูล การจัดเก็บประวัติ และการทำความสะอาด

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

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

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

ความท้าทายด้านประสิทธิภาพการผลิต

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

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

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

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

การล้างข้อมูลเก่าเป็นปัญหาสำคัญที่ส่งผลกระทบอย่างมากต่อประสิทธิภาพของฐานข้อมูล

การแคชใน Zabbix

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

การแคชที่ด้านข้างของเซิร์ฟเวอร์ Zabbix คือ:

• การกำหนดค่าแคช;
• แวลูแคช;
• ประวัติแคช;
• เทรนด์แคช

พิจารณารายละเอียดเพิ่มเติม

การกำหนดค่าแคช

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

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

การเก็บรวบรวมข้อมูล

แผนภาพมีขนาดค่อนข้างใหญ่ แต่สิ่งสำคัญในนั้นคือ นักสะสม. สิ่งเหล่านี้คือ "โพลเลอร์" ต่างๆ - กระบวนการประกอบ พวกเขามีหน้าที่รับผิดชอบในการประกอบประเภทต่างๆ: รวบรวมข้อมูลผ่าน SNMP, IPMI และถ่ายโอนข้อมูลทั้งหมดไปยังการประมวลผลล่วงหน้า

นักสะสมจะมีโครงร่างเป็นสีส้ม

Zabbix ได้คำนวณรายการรวมที่จำเป็นสำหรับการรวมเช็ค หากเรามี เราจะดึงข้อมูลสำหรับพวกเขาโดยตรงจาก ValueCache

แคชประวัติการประมวลผลล่วงหน้า

ตัวรวบรวมทั้งหมดใช้ ConfigurationCache เพื่อรับงาน จากนั้นพวกเขาก็ถ่ายโอนไปยังการประมวลผลล่วงหน้า

PreProcessing ใช้ ConfigurationCache เพื่อรับขั้นตอน PreProcessing มันประมวลผลข้อมูลนี้ในรูปแบบต่างๆ

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

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

ValueCache ประวัติและแคชแนวโน้ม

ตัวซิงค์ประวัติเป็นกระบวนการหลักที่ประมวลผลแต่ละองค์ประกอบข้อมูลแบบอะตอม ซึ่งก็คือ แต่ละค่า

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

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

ตัวซิงค์ประวัติเขียนข้อมูลทั้งหมดลงฐานข้อมูลและเขียนลงดิสก์ กระบวนการประมวลผลสิ้นสุดที่นี่

การแคชในฐานข้อมูล

ในด้านฐานข้อมูลจะมีแคชต่างๆ เมื่อคุณต้องการดูกราฟหรือรายงานเกี่ยวกับเหตุการณ์:

• Innodb_buffer_pool ทางฝั่ง MySQL;
• shared_buffers ทางฝั่ง PostgreSQL;
• effective_cache_size ทางด้านออราเคิล;
• shared_pool ทางฝั่ง DB2

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

ประสิทธิภาพของฐานข้อมูลเป็นสิ่งสำคัญ

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

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

แม่บ้าน

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

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

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

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

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

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

แม่บ้านถูกปิด กราฟปรับระดับ - อาจมีปัญหาอะไรบ้างในกรณีนี้ และอะไรจะช่วยแก้ปัญหาความท้าทายด้านประสิทธิภาพครั้งที่สามได้

การแบ่งพาร์ติชัน - การแบ่งพาร์ติชันหรือการแบ่งพาร์ติชัน

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

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

ค่าอาจมีการเปลี่ยนแปลงหาก “การตั้งค่า” มีขนาดใหญ่มาก หาก “การตั้งค่า” ขนาดเล็กสูงถึง 5 nvps (ค่าใหม่ต่อวินาที) การตั้งค่าขนาดกลางจะอยู่ระหว่าง 000 ถึง 5 ดังนั้นการตั้งค่าขนาดใหญ่จะมีค่ามากกว่า 000 nvps การติดตั้งเหล่านี้เป็นการติดตั้งขนาดใหญ่และใหญ่มากซึ่งต้องมีการกำหนดค่าฐานข้อมูลอย่างระมัดระวัง

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

การแบ่งพาร์ติชันให้อะไร?

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

การกำจัดอย่างรวดเร็ว - DELETE. เลือกหนึ่งไฟล์/ตารางย่อย แทนที่จะเลือกแถวสำหรับการลบ

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

บ่อยครั้งที่ฐานข้อมูลจำนวนมากถูกเร่งเช่นกัน INSERT - การแทรกลงในตารางลูก

ไทม์สเกลDB

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

TimescaleDB มีแนวคิด ไฮเปอร์เทเบิล (ไฮเปอร์เทเบิล) ที่คุณสร้างขึ้น ประกอบด้วย ชิ้น - พาร์ติชัน ชิ้นส่วนจะได้รับการจัดการไฮเปอร์เทเบิลแฟรกเมนต์โดยอัตโนมัติ ซึ่งจะไม่ส่งผลกระทบต่อแฟรกเมนต์อื่นๆ แต่ละอันมีช่วงเวลาของตัวเอง

TimescaleDB กับ PostgreSQL

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

หลังจากผ่านไป 200 ล้านแถว PostgreSQL มักจะเริ่มลดลงอย่างมากและสูญเสียประสิทธิภาพลงเหลือ 0 TimescaleDB ช่วยให้คุณสามารถแทรก “ส่วนแทรก” สำหรับข้อมูลจำนวนเท่าใดก็ได้ได้อย่างมีประสิทธิภาพ

การติดตั้ง

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

สำหรับฐานข้อมูล Zabbix เราเพียงเปิดใช้งานส่วนขยาย:

echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix

คุณเปิดใช้งาน extension และสร้างมันขึ้นมาสำหรับฐานข้อมูล Zabbix ขั้นตอนสุดท้ายคือการสร้างไฮเปอร์เทเบิล

การย้ายตารางประวัติไปยัง TimescaleDB

มีฟังก์ชั่นพิเศษสำหรับสิ่งนี้ create_hypertable:

SELECT create_hypertable(‘history’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_log’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_text’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_str’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
UPDATE config SET db_extension=’timescaledb’, hk_history_global=1, hk_trends_global=1

ฟังก์ชันนี้มีพารามิเตอร์สามตัว อันดับแรก - ตารางในฐานข้อมูลซึ่งคุณต้องสร้างไฮเปอร์เทเบิล ที่สอง - สนามตามที่คุณต้องสร้าง chunk_time_interval — ช่วงเวลาของพาร์ติชันที่จะใช้ ในกรณีของฉัน ช่วงเวลาคือหนึ่งวัน - 86

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

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

การกำหนดค่าฮาร์ดแวร์

ฉันใช้เซิร์ฟเวอร์สองตัว อันดับแรก - เครื่องวีเอ็มแวร์. มันค่อนข้างเล็ก: โปรเซสเซอร์ Intel® Xeon® CPU E20-5 v 2630 @ 4GHz 2.20 ตัว, RAM 16 GB และ SSD 200 GB

ฉันติดตั้ง PostgreSQL 10.8 ลงบนระบบปฏิบัติการ Debian 10.8-1.pgdg90+1 OS และระบบไฟล์ xfs ฉันกำหนดค่าทุกอย่างให้น้อยที่สุดเพื่อใช้ฐานข้อมูลเฉพาะนี้ ลบสิ่งที่ Zabbix จะใช้เอง

บนเครื่องเดียวกันมีเซิร์ฟเวอร์ Zabbix, PostgreSQL และ ตัวแทนโหลด. ฉันมีตัวแทนที่ใช้งานอยู่ 50 คนที่ใช้งานอยู่ LoadableModuleเพื่อสร้างผลลัพธ์ที่แตกต่างอย่างรวดเร็ว: ตัวเลข, สตริง ฉันเติมฐานข้อมูลด้วยข้อมูลจำนวนมาก

เริ่มแรกมีการกำหนดค่าอยู่ 5 องค์ประกอบ ข้อมูลต่อโฮสต์ เกือบทุกองค์ประกอบมีทริกเกอร์เพื่อให้คล้ายกับการติดตั้งจริง ในบางกรณีมีทริกเกอร์มากกว่าหนึ่งรายการ สำหรับโหนดเครือข่ายหนึ่งก็มี ทริกเกอร์ 3-000 ตัว.

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

PostgreSQL. 35 NVP

การรันครั้งแรกของฉันกับฮาร์ดแวร์นี้คือบน PostgreSQL ล้วนๆ - 35 ค่าต่อวินาที อย่างที่คุณเห็น การแทรกข้อมูลใช้เวลาเสี้ยววินาที - ทุกอย่างดีและรวดเร็ว สิ่งเดียวคือดิสก์ SSD ขนาด 200 GB เต็มอย่างรวดเร็ว

นี่คือแดชบอร์ดประสิทธิภาพของเซิร์ฟเวอร์ Zabbix มาตรฐาน

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

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

PostgreSQL. 50 NVP

จากนั้นฉันเพิ่มโหลดเป็น 50 ค่าต่อวินาทีบนฮาร์ดแวร์เดียวกัน

เมื่อโหลดจาก Housekeeper ใส่ค่า 10 หมื่นค่า ใช้เวลา 2-3 วินาที

แม่บ้านเริ่มยุ่งกับงานแล้ว

กราฟที่สามแสดงให้เห็นว่า โดยทั่วไปแล้ว โหลดของแทรปเปอร์และตัวซิงโครไนซ์ประวัติยังคงอยู่ที่ 60% ในกราฟที่สี่ HistoryCache กำลังเริ่มเติมเต็มระหว่างการทำงานของแม่บ้านแล้ว เต็ม 20% หรือประมาณ 0,5 GB

PostgreSQL. 80 NVP

จากนั้นฉันเพิ่มโหลดเป็น 80 ค่าต่อวินาที นี่คือองค์ประกอบข้อมูลประมาณ 400 รายการและทริกเกอร์ 280 รายการ

ค่าใช้จ่ายในการโหลดซินเชอร์ประวัติศาสตร์สามสิบตัวนั้นค่อนข้างสูงอยู่แล้ว

ฉันยังเพิ่มพารามิเตอร์ต่าง ๆ : ตัวซิงค์ประวัติ, แคช

บนฮาร์ดแวร์ของฉัน การโหลดตัวซิงค์ประวัติเพิ่มขึ้นเป็นระดับสูงสุด HistoryCache เต็มไปด้วยข้อมูลอย่างรวดเร็ว - ข้อมูลสำหรับการประมวลผลสะสมอยู่ในบัฟเฟอร์

ตลอดเวลานี้ ฉันสังเกตว่ามีการใช้โปรเซสเซอร์, RAM และพารามิเตอร์ระบบอื่นๆ อย่างไร และพบว่าการใช้งานดิสก์อยู่ที่ระดับสูงสุด

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

เซิร์ฟเวอร์ที่สอง

ฉันใช้เซิร์ฟเวอร์อื่นซึ่งมีโปรเซสเซอร์ 48 ตัวและ RAM ขนาด 128 GB อยู่แล้ว ฉันปรับมันแล้ว - ตั้งค่าเป็น 60 history syncer และได้รับประสิทธิภาพที่ยอมรับได้

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

มาตราส่วนเวลาDB. 80 NVP

งานหลักของฉันคือทดสอบความสามารถของ TimescaleDB กับโหลด Zabbix 80 ค่าต่อวินาทีนั้นมาก ความถี่ในการรวบรวมตัวชี้วัด (ยกเว้นยานเดกซ์แน่นอน) และ "การตั้งค่า" ที่ค่อนข้างใหญ่

มีการลดลงในทุกกราฟ - นี่คือการย้ายข้อมูลอย่างแม่นยำ หลังจากความล้มเหลวในเซิร์ฟเวอร์ Zabbix โปรไฟล์การโหลดของตัวซิงค์ประวัติเปลี่ยนไปมาก - ลดลงสามครั้ง

TimescaleDB ช่วยให้คุณแทรกข้อมูลเร็วขึ้นเกือบ 3 เท่า และใช้ HistoryCache น้อยลง

ดังนั้นคุณจะได้รับข้อมูลอย่างทันท่วงที

มาตราส่วนเวลาDB. 120 NVP

จากนั้นฉันเพิ่มจำนวนองค์ประกอบข้อมูลเป็น 500 ภารกิจหลักคือทดสอบความสามารถของ TimescaleDB - ฉันได้รับค่าที่คำนวณได้ 125 ค่าต่อวินาที

นี่คือ "การตั้งค่า" ที่ใช้งานได้ซึ่งสามารถทำงานได้เป็นเวลานาน แต่เนื่องจากดิสก์ของฉันมีขนาดเพียง 1,5 TB ฉันจึงเติมให้เต็มภายในสองสามวัน

สิ่งที่สำคัญที่สุดคือในเวลาเดียวกันก็มีการสร้างพาร์ติชัน TimescaleDB ใหม่

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

ตัวอย่างเช่น ฉันจะแสดงกราฟหนึ่งกราฟจากหลายๆ กราฟในชุมชน ในภาพ TimescaleDB เปิดใช้งานอยู่ ส่งผลให้ภาระการใช้ io.weight บนโปรเซสเซอร์ลดลง การใช้องค์ประกอบกระบวนการภายในก็ลดลงเช่นกัน ยิ่งไปกว่านั้น นี่เป็นเครื่องเสมือนธรรมดาบนดิสก์แพนเค้กธรรมดา ไม่ใช่ SSD

ผลการวิจัย

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

TimescaleDB กำหนดค่าได้ง่าย ให้ประสิทธิภาพเพิ่มขึ้น ทำงานได้ดีกับ Zabbix และ มีข้อได้เปรียบเหนือ PostgreSQL.

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

เมื่อเราพูดว่า "ประสิทธิภาพสูง" เราหมายถึง โหลดสูง++. คุณจะไม่ต้องรอนานเพื่อเรียนรู้เกี่ยวกับเทคโนโลยีและหลักปฏิบัติที่ช่วยให้บริการต่างๆ สามารถให้บริการแก่ผู้ใช้หลายล้านคนได้ รายการ รายงาน สำหรับวันที่ 7 และ 8 พฤศจิกายน เราได้รวบรวมไว้แล้ว แต่ที่นี่ การพบปะ สามารถแนะนำเพิ่มเติมได้

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

ที่มา: will.com