Zabbix เป็นระบบตรวจสอบ เช่นเดียวกับระบบอื่นๆ มันประสบปัญหาหลักสามประการของระบบตรวจสอบทั้งหมด: การรวบรวมและประมวลผลข้อมูล การจัดเก็บประวัติ และการทำความสะอาด
ขั้นตอนการรับ การประมวลผล และการบันทึกข้อมูลต้องใช้เวลา ไม่มากนัก แต่สำหรับระบบขนาดใหญ่ อาจส่งผลให้เกิดความล่าช้าอย่างมาก ปัญหาการจัดเก็บข้อมูลคือปัญหาการเข้าถึงข้อมูล ใช้สำหรับรายงาน การตรวจสอบ และทริกเกอร์ เวลาแฝงในการเข้าถึงข้อมูลยังส่งผลต่อประสิทธิภาพการทำงานด้วย เมื่อฐานข้อมูลเติบโตขึ้น ข้อมูลที่ไม่เกี่ยวข้องจะต้องถูกลบทิ้ง การลบออกเป็นการดำเนินการที่ยากและกินทรัพยากรบางส่วนด้วย
ปัญหาความล่าช้าระหว่างการรวบรวมและการจัดเก็บใน Zabbix ได้รับการแก้ไขโดยการแคช: แคชหลายประเภท, การแคชในฐานข้อมูล เพื่อแก้ไขปัญหาที่สาม การแคชไม่เหมาะสม ดังนั้น Zabbix จึงใช้ TimescaleDB เขาจะบอกคุณเกี่ยวกับเรื่องนี้ อันเดรย์ กูชชิน - วิศวกรสนับสนุนด้านเทคนิค
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 นั้นค่อนข้างง่ายสำหรับแพ็คเกจใดๆ ใน
สำหรับฐานข้อมูล 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