เราจะดูว่า Zabbix ทำงานอย่างไรกับฐานข้อมูล TimescaleDB ในฐานะแบ็กเอนด์ เราจะแสดงวิธีเริ่มต้นใหม่และวิธีการย้ายจาก PostgreSQL นอกจากนี้เรายังจะมีการทดสอบประสิทธิภาพเปรียบเทียบของการกำหนดค่าทั้งสองอีกด้วย
HighLoad++ ไซบีเรีย 2019 Tomsk Hall วันที่ 24 มิถุนายน เวลา 16 น. วิทยานิพนธ์และ . การประชุม HighLoad++ ครั้งต่อไปจะจัดขึ้นในวันที่ 6 และ 7 เมษายน 2020 ที่เซนต์ปีเตอร์สเบิร์ก รายละเอียดและตั๋ว .
Andrey Gushchin (ต่อไปนี้ – AG): – ฉันเป็นวิศวกรสนับสนุนด้านเทคนิคของ ZABBIX (ต่อไปนี้จะเรียกว่า “Zabbix”) ซึ่งเป็นผู้ฝึกสอน ฉันทำงานด้านการสนับสนุนด้านเทคนิคมามากกว่า 6 ปีและมีประสบการณ์ตรงด้านการปฏิบัติงาน วันนี้ผมจะพูดถึงประสิทธิภาพที่ TimescaleDB สามารถให้ได้เมื่อเปรียบเทียบกับ PostgreSQL 10 ปกติ นอกจากนี้ ยังมีส่วนเบื้องต้นเกี่ยวกับวิธีการทำงานโดยทั่วไปอีกด้วย
ความท้าทายด้านประสิทธิภาพสูงสุด: ตั้งแต่การรวบรวมข้อมูลไปจนถึงการล้างข้อมูล
ประการแรก มีความท้าทายด้านประสิทธิภาพบางประการที่ทุกระบบการตรวจสอบต้องเผชิญ ความท้าทายด้านประสิทธิภาพประการแรกคือการรวบรวมและประมวลผลข้อมูลอย่างรวดเร็ว
ระบบการตรวจสอบที่ดีควรได้รับข้อมูลทั้งหมดอย่างรวดเร็ว ทันเวลา ประมวลผลตามนิพจน์ทริกเกอร์ กล่าวคือ ประมวลผลตามเกณฑ์บางประการ (ซึ่งแตกต่างกันในแต่ละระบบ) และบันทึกไว้ในฐานข้อมูลเพื่อใช้ข้อมูลนี้ใน อนาคต.
ความท้าทายด้านประสิทธิภาพประการที่สองคือการจัดเก็บประวัติ จัดเก็บในฐานข้อมูลบ่อยครั้งและเข้าถึงตัวชี้วัดเหล่านี้ที่รวบรวมไว้ในช่วงเวลาหนึ่งได้อย่างรวดเร็วและสะดวก สิ่งที่สำคัญที่สุดคือข้อมูลนี้สะดวกในการรับ ใช้ในรายงาน กราฟ ทริกเกอร์ ในค่าเกณฑ์บางค่า สำหรับการแจ้งเตือน ฯลฯ
ความท้าทายด้านประสิทธิภาพประการที่สามคือการล้างประวัติ นั่นคือเมื่อคุณไปถึงจุดที่คุณไม่จำเป็นต้องจัดเก็บเมตริกโดยละเอียดใดๆ ที่รวบรวมไว้นานกว่า 5 ปี (แม้แต่เดือนหรือสองเดือนก็ตาม) โหนดเครือข่ายบางโหนดถูกลบหรือบางโฮสต์ เมตริกนั้นไม่จำเป็นอีกต่อไป เนื่องจากโหนดเหล่านั้นล้าสมัยแล้วและไม่ได้รวบรวมอีกต่อไป ทั้งหมดนี้จำเป็นต้องได้รับการทำความสะอาดเพื่อไม่ให้ฐานข้อมูลของคุณใหญ่เกินไป โดยทั่วไปแล้ว การล้างประวัติมักเป็นการทดสอบที่จริงจังสำหรับพื้นที่จัดเก็บข้อมูล ซึ่งมักจะมีผลกระทบอย่างมากต่อประสิทธิภาพการทำงาน
วิธีแก้ปัญหาแคช?
ตอนนี้ฉันจะพูดถึง Zabbix โดยเฉพาะ ใน Zabbix การโทรครั้งแรกและครั้งที่สองได้รับการแก้ไขโดยใช้แคช
การรวบรวมและประมวลผลข้อมูล - เราใช้ RAM เพื่อจัดเก็บข้อมูลทั้งหมดนี้ ข้อมูลเหล่านี้จะมีการหารือในรายละเอียดเพิ่มเติม
นอกจากนี้ในด้านฐานข้อมูลยังมีแคชสำหรับการเลือกหลัก - สำหรับกราฟและสิ่งอื่น ๆ
การแคชที่ด้านข้างของเซิร์ฟเวอร์ Zabbix: เรามี ConfigurationCache, ValueCache, HistoryCache, TrendsCache มันคืออะไร?
ConfigurationCache เป็นแคชหลักที่เราจัดเก็บหน่วยวัด โฮสต์ รายการข้อมูล ทริกเกอร์ ทุกสิ่งที่คุณต้องการในการประมวลผลล่วงหน้า รวบรวมข้อมูล จากโฮสต์ที่จะรวบรวม ด้วยความถี่เท่าใด ทั้งหมดนี้ถูกเก็บไว้ใน ConfigurationCache เพื่อไม่ให้ไปที่ฐานข้อมูลและสร้างแบบสอบถามที่ไม่จำเป็น หลังจากที่เซิร์ฟเวอร์เริ่มทำงาน เราจะอัปเดตแคชนี้ (สร้าง) และอัปเดตเป็นระยะ (ขึ้นอยู่กับการตั้งค่าการกำหนดค่า)
การแคชใน Zabbix การเก็บรวบรวมข้อมูล
แผนภาพนี้ค่อนข้างใหญ่:
สิ่งสำคัญในโครงการคือนักสะสมเหล่านี้:
เหล่านี้เป็นกระบวนการประกอบเอง "โพลเลอร์" ต่างๆ ที่รับผิดชอบในการประกอบประเภทต่างๆ พวกเขารวบรวมข้อมูลผ่าน icmp, ipmi และโปรโตคอลต่างๆ และถ่ายโอนข้อมูลทั้งหมดไปยังการประมวลผลล่วงหน้า
แคชประวัติการประมวลผลล่วงหน้า
นอกจากนี้ หากเรามีองค์ประกอบข้อมูลที่คำนวณ (ผู้ที่คุ้นเคยกับ Zabbix รู้) นั่นคือองค์ประกอบข้อมูลที่รวบรวมจากการคำนวณ เราจะนำองค์ประกอบเหล่านั้นมาจาก ValueCache โดยตรง ผมจะเล่าให้ฟังทีหลัง ตัวรวบรวมเหล่านี้ทั้งหมดใช้ ConfigurationCache เพื่อรับงานของตน จากนั้นส่งต่อไปยังการประมวลผลล่วงหน้า
การประมวลผลล่วงหน้ายังใช้ ConfigurationCache เพื่อรับขั้นตอนการประมวลผลล่วงหน้าและประมวลผลข้อมูลนี้ในรูปแบบต่างๆ ตั้งแต่เวอร์ชัน 4.2 เราได้ย้ายไปยังพร็อกซีแล้ว สะดวกมาก เนื่องจากการประมวลผลล่วงหน้าเป็นการดำเนินการที่ค่อนข้างยาก และหากคุณมี Zabbix ที่มีขนาดใหญ่มาก โดยมีองค์ประกอบข้อมูลจำนวนมากและมีความถี่ในการรวบรวมสูง สิ่งนี้จะทำให้งานง่ายขึ้นอย่างมาก
ดังนั้น หลังจากที่เราประมวลผลข้อมูลนี้ด้วยวิธีใดวิธีหนึ่งโดยใช้การประมวลผลล่วงหน้า เราจะบันทึกข้อมูลนั้นไว้ใน HistoryCache เพื่อดำเนินการต่อไป นี่เป็นการสรุปการรวบรวมข้อมูล เราไปยังกระบวนการหลัก
งานซิงค์ประวัติ
กระบวนการหลักใน Zabbix (เนื่องจากเป็นสถาปัตยกรรมเสาหิน) คือตัวซิงค์ประวัติ นี่เป็นกระบวนการหลักที่เกี่ยวข้องกับการประมวลผลอะตอมมิกขององค์ประกอบข้อมูลแต่ละรายการโดยเฉพาะ ซึ่งก็คือ แต่ละค่า:
- ค่ามา (นำมาจาก HistoryCache);
- ตรวจสอบในตัวซิงค์การกำหนดค่า: มีทริกเกอร์สำหรับการคำนวณหรือไม่ - คำนวณ
หากมี - สร้างเหตุการณ์ สร้างการยกระดับเพื่อสร้างการแจ้งเตือน หากจำเป็น ตามการกำหนดค่า - บันทึกทริกเกอร์สำหรับการประมวลผล การรวมกลุ่มในภายหลัง หากคุณรวมในชั่วโมงที่ผ่านมาและอื่นๆ ค่านี้จะถูกจดจำโดย ValueCache เพื่อไม่ให้ไปที่ตารางประวัติ ดังนั้น ValueCache จึงเต็มไปด้วยข้อมูลที่จำเป็นซึ่งจำเป็นในการคำนวณทริกเกอร์ องค์ประกอบที่คำนวณ ฯลฯ
- จากนั้นตัวซิงค์ประวัติจะเขียนข้อมูลทั้งหมดลงในฐานข้อมูล
- ฐานข้อมูลเขียนลงดิสก์ - นี่คือจุดที่กระบวนการประมวลผลสิ้นสุดลง
ฐานข้อมูล เก็บเอาไว้
ในด้านฐานข้อมูล เมื่อคุณต้องการดูกราฟหรือรายงานเหตุการณ์บางส่วน จะมีแคชต่างๆ มากมาย แต่ในรายงานนี้ฉันจะไม่พูดถึงพวกเขา
สำหรับ MySQL จะมี Innodb_buffer_pool และแคชต่างๆ มากมายที่สามารถกำหนดค่าได้
แต่สิ่งเหล่านี้คือสิ่งหลัก:
- shared_buffers;
- มีประสิทธิภาพ_แคช_ขนาด;
- shared_pool.
สำหรับฐานข้อมูลทั้งหมด ฉันบอกว่ามีแคชบางตัวที่อนุญาตให้คุณจัดเก็บข้อมูลใน RAM ซึ่งมักจำเป็นสำหรับการสืบค้น พวกเขามีเทคโนโลยีของตัวเองสำหรับสิ่งนี้
เกี่ยวกับประสิทธิภาพของฐานข้อมูล
ดังนั้นจึงมีสภาพแวดล้อมการแข่งขัน นั่นคือเซิร์ฟเวอร์ Zabbix รวบรวมข้อมูลและบันทึกข้อมูลดังกล่าว เมื่อรีสตาร์ทก็ยังอ่านจากประวัติเพื่อเติม ValueCache และอื่นๆ ที่นี่คุณสามารถมีสคริปต์และรายงานที่ใช้ Zabbix API ซึ่งสร้างขึ้นบนเว็บอินเตอร์เฟส Zabbix API เข้าสู่ฐานข้อมูลและรับข้อมูลที่จำเป็นเพื่อรับกราฟ รายงาน หรือรายการเหตุการณ์บางประเภท ปัญหาล่าสุด
โซลูชันการแสดงภาพยอดนิยมอีกอย่างหนึ่งก็คือ Grafana ซึ่งผู้ใช้ของเราใช้ สามารถเข้าสู่ระบบได้โดยตรงทั้งผ่าน Zabbix API และผ่านฐานข้อมูล นอกจากนี้ยังสร้างการแข่งขันในการรับข้อมูล: จำเป็นต้องมีการปรับแต่งฐานข้อมูลอย่างละเอียดและดีขึ้นเพื่อให้สอดคล้องกับการส่งมอบผลลัพธ์และการทดสอบที่รวดเร็ว
การล้างประวัติ แซ่บบิกซ์มีแม่บ้าน
การโทรครั้งที่สามที่ใช้ใน Zabbix คือการล้างประวัติโดยใช้แม่บ้าน แม่บ้านจะติดตามการตั้งค่าทั้งหมด นั่นคือ องค์ประกอบข้อมูลของเราระบุระยะเวลาในการจัดเก็บ (เป็นวัน) ระยะเวลาในการจัดเก็บแนวโน้ม และพลวัตของการเปลี่ยนแปลง
ฉันไม่ได้พูดถึง TrendCache ซึ่งเราคำนวณทันที: ข้อมูลมาถึง เรารวบรวมไว้หนึ่งชั่วโมง (ส่วนใหญ่เป็นตัวเลขของชั่วโมงที่ผ่านมา) จำนวนเป็นค่าเฉลี่ย/ขั้นต่ำ และเราบันทึกมันหนึ่งครั้งต่อชั่วโมงใน ตารางพลวัตของการเปลี่ยนแปลง (“แนวโน้ม”) “แม่บ้าน” เริ่มต้นและลบข้อมูลจากฐานข้อมูลโดยใช้การเลือกปกติ ซึ่งอาจไม่ได้ผลเสมอไป
จะเข้าใจได้อย่างไรว่าไม่ได้ผล? คุณสามารถเห็นภาพต่อไปนี้บนกราฟประสิทธิภาพของกระบวนการภายใน:
ตัวซิงค์ประวัติของคุณยุ่งตลอดเวลา (กราฟสีแดง) และกราฟ “สีแดง” ที่อยู่ด้านบน นี่คือ “แม่บ้าน” ที่เริ่มต้นและรอให้ฐานข้อมูลลบแถวทั้งหมดที่ระบุไว้
ลองใช้ Item ID บ้าง: คุณต้องลบ 5 รายการสุดท้าย แน่นอนตามดัชนี แต่โดยปกติแล้วชุดข้อมูลจะมีขนาดค่อนข้างใหญ่ - ฐานข้อมูลยังคงอ่านจากดิสก์และวางลงในแคช และนี่เป็นการดำเนินการที่มีราคาแพงมากสำหรับฐานข้อมูล สิ่งนี้อาจทำให้เกิดปัญหาด้านประสิทธิภาพบางอย่างได้ ทั้งนี้ขึ้นอยู่กับขนาดของมัน
คุณสามารถปิดการใช้งาน Housekeeper ได้อย่างง่ายดาย - เรามีเว็บอินเตอร์เฟสที่คุ้นเคย การตั้งค่าในการดูแลระบบทั่วไป (การตั้งค่าสำหรับ "แม่บ้าน") เราปิดใช้งานการดูแลทำความสะอาดภายในสำหรับประวัติและแนวโน้มภายใน ดังนั้นแม่บ้านจึงไม่ควบคุมสิ่งนี้อีกต่อไป:
คุณสามารถทำอะไรต่อไป? คุณปิดมัน กราฟของคุณปรับระดับแล้ว... ในกรณีนี้จะเกิดปัญหาอะไรอีก? ช่วยอะไรได้บ้าง?
การแบ่งส่วน (การแบ่งส่วน)
โดยทั่วไปแล้วจะมีการกำหนดค่าในลักษณะที่แตกต่างกันในแต่ละฐานข้อมูลเชิงสัมพันธ์ที่ฉันระบุไว้ MySQL มีเทคโนโลยีของตัวเอง แต่โดยรวมแล้วพวกมันคล้ายกันมากเมื่อพูดถึง PostgreSQL 10 และ MySQL แน่นอนว่ามีความแตกต่างภายในมากมายเกี่ยวกับวิธีการนำไปใช้และผลกระทบทั้งหมดต่อประสิทธิภาพการทำงาน แต่โดยทั่วไปแล้ว การสร้างพาร์ติชันใหม่มักจะนำไปสู่ปัญหาบางอย่างเช่นกัน
ขึ้นอยู่กับการตั้งค่าของคุณ (จำนวนข้อมูลที่คุณสร้างในหนึ่งวัน) โดยปกติแล้วจะตั้งค่าขั้นต่ำ - นี่คือ 1 วัน / ชุด และสำหรับ "แนวโน้ม" การเปลี่ยนแปลงแบบไดนามิก - 1 เดือน / ชุดใหม่ สิ่งนี้อาจเปลี่ยนแปลงได้หากคุณมีการตั้งค่าที่มีขนาดใหญ่มาก
สมมติว่าทันทีเกี่ยวกับขนาดของการตั้งค่า: มากถึง 5 ค่าใหม่ต่อวินาที (เรียกว่า nvps) - นี่จะถือเป็น "การตั้งค่า" ขนาดเล็ก เฉลี่ย – ตั้งแต่ 5 ถึง 25 ค่าต่อวินาที สิ่งที่กล่าวมาข้างต้นเป็นการติดตั้งที่มีขนาดใหญ่และใหญ่มากซึ่งต้องมีการกำหนดค่าฐานข้อมูลอย่างระมัดระวัง
สำหรับการติดตั้งที่มีขนาดใหญ่มาก ระยะเวลา 1 วันอาจไม่เหมาะสม โดยส่วนตัวแล้วฉันเคยเห็นพาร์ติชันบน MySQL ขนาด 40 กิกะไบต์ต่อวัน (และอาจมีมากกว่านั้น) นี่เป็นข้อมูลจำนวนมากซึ่งอาจนำไปสู่ปัญหาบางอย่างได้ มันจำเป็นต้องลดลง
ทำไมคุณต้องมีการแบ่งพาร์ติชัน?
ฉันคิดว่าทุกคนรู้ดีว่าการแบ่งพาร์ติชันมีอะไรบ้างคือการแบ่งพาร์ติชันตาราง บ่อยครั้งไฟล์เหล่านี้เป็นไฟล์แยกกันบนดิสก์และคำขอขยาย จะเลือกหนึ่งพาร์ติชันอย่างเหมาะสมที่สุดหากเป็นส่วนหนึ่งของการแบ่งพาร์ติชันปกติ
โดยเฉพาะอย่างยิ่งสำหรับ Zabbix มันถูกใช้ตามช่วง ตามช่วง นั่นคือ เราใช้การประทับเวลา (ตัวเลขปกติ เวลาตั้งแต่ต้นยุค) คุณระบุจุดเริ่มต้นของวัน/สิ้นสุดของวัน และนี่คือพาร์ติชัน ดังนั้น หากคุณขอข้อมูลที่มีอายุสองวัน ทุกอย่างจะถูกดึงจากฐานข้อมูลเร็วขึ้น เนื่องจากคุณจะต้องโหลดไฟล์เดียวลงในแคชแล้วส่งคืน (แทนที่จะเป็นตารางขนาดใหญ่)
ฐานข้อมูลจำนวนมากยังเร่งความเร็วการแทรก (การแทรกลงในตารางลูกเดียว) ตอนนี้ฉันกำลังพูดแบบนามธรรม แต่ก็เป็นไปได้เช่นกัน การแบ่งส่วนมักจะช่วยได้
การค้นหาแบบยืดหยุ่นสำหรับ NoSQL
เมื่อเร็วๆ นี้ ในเวอร์ชัน 3.4 เราได้ใช้โซลูชัน NoSQL เพิ่มความสามารถในการเขียนใน Elasticsearch คุณสามารถเขียนบางประเภท: คุณเลือก - เขียนตัวเลขหรือเครื่องหมายบางอย่าง; เรามีข้อความสตริง คุณสามารถเขียนบันทึกไปที่ Elasticsearch... ดังนั้น เว็บอินเทอร์เฟซก็จะเข้าถึง Elasticsearch ด้วยเช่นกัน วิธีนี้ใช้ได้ผลดีในบางกรณี แต่ในขณะนี้ก็สามารถใช้ได้
มาตราส่วนเวลาDB. ไฮเปอร์เทเบิล
สำหรับ 4.4.2 เราให้ความสนใจกับสิ่งหนึ่งเช่น TimescaleDB มันคืออะไร? นี่คือส่วนขยายสำหรับ PostgreSQL นั่นคือมีอินเทอร์เฟซ PostgreSQL ดั้งเดิม นอกจากนี้ส่วนขยายนี้ยังช่วยให้คุณทำงานได้อย่างมีประสิทธิภาพมากขึ้นกับข้อมูลอนุกรมเวลาและมีการแบ่งพาร์ติชันอัตโนมัติ ดูเหมือนว่า:
นี่คือไฮเปอร์เทเบิล - มีแนวคิดดังกล่าวในไทม์สเกล นี่คือไฮเปอร์เทเบิลที่คุณสร้างขึ้น และประกอบด้วยชิ้นส่วนต่างๆ ชิ้นคือพาร์ติชั่น นี่คือตารางย่อย ถ้าจำไม่ผิด มันได้ผลจริงๆ
TimescaleDB และ PostgreSQL
ตามที่ผู้ผลิต TimescaleDB ให้ความมั่นใจ พวกเขาใช้อัลกอริธึมที่ถูกต้องมากขึ้นในการประมวลผลการสืบค้น โดยเฉพาะส่วนแทรก ซึ่งช่วยให้พวกเขามีประสิทธิภาพที่คงที่โดยประมาณโดยเพิ่มขนาดการแทรกชุดข้อมูลที่เพิ่มขึ้น นั่นคือหลังจาก Postgres 200 ล้านแถว แถวปกติจะเริ่มลดลงอย่างมากและสูญเสียประสิทธิภาพอย่างแท้จริงจนเหลือศูนย์ ในขณะที่ Timescale ช่วยให้คุณสามารถแทรกส่วนแทรกได้อย่างมีประสิทธิภาพมากที่สุดเท่าที่จะเป็นไปได้กับข้อมูลจำนวนเท่าใดก็ได้
จะติดตั้ง TimescaleDB ได้อย่างไร? มันง่ายมาก!
อยู่ในเอกสารตามที่อธิบายไว้ - คุณสามารถติดตั้งได้จากแพ็คเกจใดก็ได้... ขึ้นอยู่กับแพ็คเกจ Postgres อย่างเป็นทางการ สามารถคอมไพล์ได้ด้วยตนเอง เลยบังเอิญต้องคอมไพล์ลงฐานข้อมูล
บน Zabbix เราเพียงแค่เปิดใช้งานส่วนขยาย ฉันคิดว่าผู้ที่ใช้ Extension ใน Postgres... คุณเพียงเปิดใช้งาน Extention สร้างมันขึ้นมาสำหรับฐานข้อมูล Zabbix ที่คุณใช้อยู่
และขั้นตอนสุดท้าย...
มาตราส่วนเวลาDB. การโยกย้ายของตารางประวัติศาสตร์
คุณต้องสร้างไฮเปอร์เทเบิล มีฟังก์ชั่นพิเศษสำหรับสิ่งนี้ – สร้างไฮเปอร์เทเบิล ในนั้นพารามิเตอร์แรกคือตารางที่จำเป็นในฐานข้อมูลนี้ (ซึ่งคุณต้องสร้างไฮเปอร์เทเบิล)
ฟิลด์ที่จะสร้างและ chunk_time_interval (นี่คือช่วงเวลาของชิ้นส่วน (พาร์ติชันที่จำเป็นต้องใช้) 86 คือหนึ่งวัน
พารามิเตอร์ Migrate_data: หากคุณแทรกเป็นจริง ระบบจะย้ายข้อมูลปัจจุบันทั้งหมดไปยังชิ้นส่วนที่สร้างไว้ล่วงหน้า
ฉันเคยใช้ movege_data ด้วยตัวเอง ซึ่งใช้เวลานานพอสมควร ขึ้นอยู่กับว่าฐานข้อมูลของคุณใหญ่แค่ไหน ฉันมีมากกว่าเทราไบต์ - ใช้เวลาสร้างนานกว่าหนึ่งชั่วโมง ในบางกรณี ในระหว่างการทดสอบ ฉันได้ลบข้อมูลประวัติสำหรับข้อความ (history_text) และสตริง (history_str) เพื่อไม่ให้ถ่ายโอนข้อมูลเหล่านั้น - ข้อมูลเหล่านั้นไม่น่าสนใจสำหรับฉันจริงๆ
และเราทำการอัปเดตครั้งล่าสุดใน db_extention ของเรา: เราติดตั้ง timescaledb เพื่อให้ฐานข้อมูลและโดยเฉพาะ Zabbix ของเราเข้าใจว่ามี db_extention เขาเปิดใช้งานและใช้ไวยากรณ์และการสืบค้นที่ถูกต้องไปยังฐานข้อมูล โดยใช้ “คุณสมบัติ” เหล่านั้นที่จำเป็นสำหรับ TimescaleDB
การกำหนดค่าเซิร์ฟเวอร์
ฉันใช้เซิร์ฟเวอร์สองตัว เซิร์ฟเวอร์เครื่องแรกคือเครื่องเสมือนที่มีขนาดค่อนข้างเล็ก มีโปรเซสเซอร์ 20 ตัว และ RAM ขนาด 16 กิกะไบต์ ฉันกำหนดค่า Postgres 10.8 ไว้:
ระบบปฏิบัติการคือ Debian ระบบไฟล์คือ xfs ฉันตั้งค่าขั้นต่ำเพื่อใช้ฐานข้อมูลนี้โดยเฉพาะ ลบสิ่งที่ Zabbix จะใช้ บนเครื่องเดียวกันมีเซิร์ฟเวอร์ Zabbix, PostgreSQL และเอเจนต์โหลด
ฉันใช้ตัวแทนที่ทำงานอยู่ 50 รายที่ใช้ LoadableModule เพื่อสร้างผลลัพธ์ที่แตกต่างอย่างรวดเร็ว พวกเขาคือผู้สร้างสตริง ตัวเลข และอื่นๆ ฉันเติมฐานข้อมูลด้วยข้อมูลจำนวนมาก เริ่มแรก การกำหนดค่ามีองค์ประกอบข้อมูล 5 รายการต่อโฮสต์ และองค์ประกอบข้อมูลแต่ละองค์ประกอบโดยประมาณมีทริกเกอร์ เพื่อให้สิ่งนี้เป็นการตั้งค่าจริง บางครั้งคุณจำเป็นต้องมีทริกเกอร์มากกว่าหนึ่งตัวจึงจะใช้งานได้
ฉันควบคุมช่วงเวลาการอัปเดตและโหลดเองโดยไม่เพียงแต่ใช้ 50 เอเจนต์ (เพิ่มมากขึ้น) แต่ยังใช้องค์ประกอบข้อมูลแบบไดนามิกและลดช่วงเวลาการอัปเดตเหลือ 4 วินาที
การทดสอบประสิทธิภาพ PostgreSQL: 36 NVP
การเปิดตัวครั้งแรก การตั้งค่าครั้งแรกที่ฉันมีคือบน PostreSQL 10 ล้วนๆ บนฮาร์ดแวร์นี้ (35 ค่าต่อวินาที) โดยทั่วไปอย่างที่คุณเห็นบนหน้าจอ การแทรกข้อมูลใช้เวลาเสี้ยววินาที - ทุกอย่างดีและรวดเร็ว ไดรฟ์ SSD (200 กิกะไบต์) สิ่งเดียวคือ 20 GB เต็มเร็วมาก
ในอนาคตจะมีกราฟลักษณะนี้เกิดขึ้นค่อนข้างมาก นี่คือแดชบอร์ดประสิทธิภาพของเซิร์ฟเวอร์ Zabbix มาตรฐาน
กราฟแรกคือจำนวนค่าต่อวินาที (สีน้ำเงิน ซ้ายบน) ในกรณีนี้คือ 35 ค่า นี่ (กลางบน) คือการโหลดกระบวนการสร้าง และนี่ (บนขวา) คือการโหลดกระบวนการภายใน: ตัวซิงค์ประวัติและแม่บ้าน ซึ่งที่นี่ (กลางล่าง) ทำงานมาระยะหนึ่งแล้ว
กราฟนี้ (ตรงกลางด้านล่าง) แสดงการใช้ ValueCache - จำนวน ValueCache ที่จะเข้าใช้ทริกเกอร์ (หลายพันค่าต่อวินาที) กราฟที่สำคัญอีกกราฟหนึ่งคือกราฟที่สี่ (ซ้ายล่าง) ซึ่งแสดงการใช้ HistoryCache ที่ผมพูดถึงซึ่งเป็นบัฟเฟอร์ก่อนที่จะแทรกลงในฐานข้อมูล
การทดสอบประสิทธิภาพ PostgreSQL: 50 NVP
ต่อไปฉันเพิ่มโหลดเป็น 50 ค่าต่อวินาทีบนฮาร์ดแวร์เดียวกัน เมื่อโหลดโดย Housekeeper จะมีการบันทึกค่า 10 ค่าใน 2-3 วินาทีพร้อมการคำนวณ ที่จริงแล้ว อะไรแสดงอยู่ในภาพหน้าจอต่อไปนี้:
“ แม่บ้าน” เริ่มเข้ามายุ่งเกี่ยวกับงานแล้ว แต่โดยทั่วไปภาระของผู้วางกับดักที่จมประวัติศาสตร์ยังอยู่ที่ระดับ 60% (กราฟที่สามมุมขวาบน) HistoryCache เริ่มเติมเต็มในขณะที่ Housekeeper กำลังทำงานอยู่ (ซ้ายล่าง) มีขนาดประมาณครึ่งกิกะไบต์ เต็ม 20%
การทดสอบประสิทธิภาพ PostgreSQL: 80 NVP
จากนั้นฉันก็เพิ่มเป็น 80 ค่าต่อวินาที:
มีองค์ประกอบข้อมูลประมาณ 400 รายการ และทริกเกอร์ 280 รายการ อย่างที่คุณเห็นการแทรกในแง่ของภาระของตัวจมประวัติศาสตร์ (มี 30 ตัว) นั้นค่อนข้างสูงอยู่แล้ว จากนั้นฉันก็เพิ่มพารามิเตอร์ต่างๆ: ตัวเก็บประวัติ แคช... บนฮาร์ดแวร์นี้ภาระของตัวเก็บประวัติเริ่มเพิ่มขึ้นเป็นสูงสุดเกือบ "บนชั้นวาง" - ด้วยเหตุนี้ HistoryCache จึงเข้าสู่โหลดที่สูงมาก:
ตลอดเวลานี้ ฉันตรวจสอบพารามิเตอร์ระบบทั้งหมด (วิธีใช้โปรเซสเซอร์ RAM) และพบว่าการใช้งานดิสก์สูงสุด - ฉันได้รับความจุสูงสุดของดิสก์นี้บนฮาร์ดแวร์นี้บนเครื่องเสมือนนี้ "Postgres" เริ่มถ่ายโอนข้อมูลในระดับความเข้มข้นดังกล่าว และดิสก์ก็ไม่มีเวลาเขียน อ่าน...
ฉันใช้เซิร์ฟเวอร์อื่นที่มีโปรเซสเซอร์ 48 ตัวและ RAM 128 กิกะไบต์อยู่แล้ว:
ฉันยัง "ปรับแต่ง" ด้วย - ติดตั้ง History syncer (60 ชิ้น) และได้รับประสิทธิภาพที่ยอมรับได้ ในความเป็นจริง เราไม่ได้ "อยู่บนชั้นวาง" แต่นี่อาจเป็นขีดจำกัดของประสิทธิภาพการทำงาน ซึ่งจำเป็นต้องดำเนินการบางอย่างเกี่ยวกับเรื่องนี้อยู่แล้ว
การทดสอบประสิทธิภาพ TimescaleDB: 80 NVP
งานหลักของฉันคือการใช้ TimescaleDB แต่ละกราฟแสดงการลดลง:
ความล้มเหลวเหล่านี้เป็นการย้ายข้อมูลอย่างแม่นยำ หลังจากนั้นในเซิร์ฟเวอร์ Zabbix โปรไฟล์การโหลดของ sinkers ประวัติศาสตร์อย่างที่คุณเห็นเปลี่ยนไปมาก ช่วยให้คุณสามารถแทรกข้อมูลได้เร็วขึ้นเกือบ 3 เท่า และใช้ HistoryCache น้อยลง ดังนั้นคุณจึงสามารถส่งข้อมูลได้ตรงเวลา อีกครั้ง 80 ค่าต่อวินาทีเป็นอัตราที่ค่อนข้างสูง (แน่นอนไม่ใช่สำหรับยานเดกซ์) โดยรวมแล้วนี่เป็นการตั้งค่าที่ค่อนข้างใหญ่โดยมีเซิร์ฟเวอร์เดียว
การทดสอบประสิทธิภาพ PostgreSQL: 120 NVP
ต่อไปฉันเพิ่มมูลค่าของจำนวนองค์ประกอบข้อมูลเป็นครึ่งล้านและรับค่าที่คำนวณได้ 125 ต่อวินาที:
และฉันได้กราฟเหล่านี้:
โดยหลักการแล้ว นี่คือการตั้งค่าการทำงาน ซึ่งสามารถทำงานได้ค่อนข้างนาน แต่เนื่องจากฉันมีดิสก์ขนาด 1,5 เทราไบต์ ฉันจึงใช้มันหมดภายในสองสามวัน สิ่งที่สำคัญที่สุดคือในเวลาเดียวกันก็มีการสร้างพาร์ติชั่นใหม่บน TimescaleDB และประสิทธิภาพการทำงานนี้ไม่มีใครสังเกตเห็นเลยซึ่งไม่สามารถพูดเกี่ยวกับ MySQL ได้
โดยทั่วไปแล้ว พาร์ติชันจะถูกสร้างขึ้นในเวลากลางคืน เนื่องจากโดยทั่วไปจะบล็อกการแทรกและทำงานกับตาราง และอาจนำไปสู่การลดประสิทธิภาพของบริการได้ ในกรณีนี้มันไม่ใช่แบบนั้น! ภารกิจหลักคือการทดสอบความสามารถของ TimescaleDB ผลลัพธ์ที่ได้คือตัวเลขต่อไปนี้: 120 ค่าต่อวินาที
นอกจากนี้ยังมีตัวอย่างในชุมชน:
บุคคลนั้นยังเปิด TimescaleDB และโหลดโดยใช้ io.weight ลดลงบนโปรเซสเซอร์ และการใช้องค์ประกอบกระบวนการภายในก็ลดลงเนื่องจากการรวม TimescaleDB ยิ่งกว่านั้นนี่คือดิสก์แพนเค้กธรรมดานั่นคือเครื่องเสมือนธรรมดาบนดิสก์ธรรมดา (ไม่ใช่ SSD)!
สำหรับการตั้งค่าเล็กๆ น้อยๆ บางอย่างที่ถูกจำกัดด้วยประสิทธิภาพของดิสก์ ฉันคิดว่า TimescaleDB เป็นโซลูชันที่ดีมาก จะช่วยให้คุณทำงานต่อไปได้ก่อนที่จะย้ายไปยังฮาร์ดแวร์ที่เร็วขึ้นสำหรับฐานข้อมูล
ฉันขอเชิญคุณเข้าร่วมกิจกรรมของเรา: การประชุมในมอสโก การประชุมสุดยอดในริกา ใช้ช่องทางของเรา - Telegram, ฟอรั่ม, IRC หากคุณมีคำถามใดๆ มาที่โต๊ะของเรา เราสามารถพูดคุยได้ทุกเรื่อง
คำถามจากผู้ชม
คำถามจากผู้ชม (ต่อไปนี้ - A): - หาก TimescaleDB กำหนดค่าได้ง่ายมากและช่วยเพิ่มประสิทธิภาพดังกล่าว บางทีนี่อาจใช้เป็นแนวทางปฏิบัติที่ดีที่สุดในการกำหนดค่า Zabbix ด้วย Postgres และมีข้อผิดพลาดและข้อเสียของโซลูชันนี้หรือไม่ หรือหากฉันตัดสินใจสร้าง Zabbix ด้วยตัวเอง ฉันสามารถใช้ Postgres ติดตั้ง Timescale ที่นั่นได้ทันที ใช้งานโดยไม่ต้องกังวลถึงปัญหาใด ๆ
เอจี: – ใช่ ฉันจะบอกว่านี่เป็นคำแนะนำที่ดี: ใช้ Postgres ทันทีกับส่วนขยาย TimescaleDB ดังที่ฉันได้กล่าวไปแล้ว มีบทวิจารณ์ที่ดีมากมาย แม้ว่า "ฟีเจอร์" นี้จะเป็นการทดลองก็ตาม แต่การทดสอบจริง ๆ แล้วแสดงให้เห็นว่านี่เป็นวิธีแก้ปัญหาที่ยอดเยี่ยม (ด้วย TimescaleDB) และฉันคิดว่ามันจะพัฒนาไป! เรากำลังติดตามดูว่าส่วนขยายนี้พัฒนาอย่างไรและจะทำการเปลี่ยนแปลงตามความจำเป็น
แม้ในระหว่างการพัฒนา เราก็อาศัยหนึ่งใน "คุณสมบัติ" ที่รู้จักกันดี: คุณสามารถทำงานกับชิ้นส่วนต่าง ๆ เล็กน้อยได้ แต่แล้วพวกเขาก็ตัดมันออกไปในรุ่นถัดไป และเราต้องหยุดพึ่งพาโค้ดนี้ ฉันอยากจะแนะนำให้ใช้โซลูชันนี้กับการตั้งค่าต่างๆ หากคุณใช้ MySQL... สำหรับการตั้งค่าโดยเฉลี่ย โซลูชันใดๆ ก็ใช้ได้ดี
NS: – กราฟสุดท้ายจากชุมชนมีกราฟที่มี “แม่บ้าน”:
เขาทำงานต่อ Housekeeper ทำอะไรกับ TimescaleDB?
เอจี: – ตอนนี้ฉันไม่สามารถพูดได้อย่างแน่นอน – ฉันจะดูโค้ดและบอกคุณในรายละเอียดเพิ่มเติม ใช้คำสั่ง TimescaleDB เพื่อไม่ให้ลบชิ้นส่วน แต่จะรวมเข้าด้วยกัน ฉันยังไม่พร้อมที่จะตอบคำถามทางเทคนิคนี้ เราจะหาข้อมูลเพิ่มเติมที่บูธวันนี้หรือพรุ่งนี้
NS: – ฉันมีคำถามที่คล้ายกัน – เกี่ยวกับประสิทธิภาพของการดำเนินการลบใน Timescale
ตอบ (คำตอบจากผู้ฟัง): – เมื่อคุณลบข้อมูลออกจากตาราง หากคุณลบข้อมูล คุณจะต้องดำเนินการทั่วทั้งตาราง - ลบ ทำความสะอาด ทำเครื่องหมายทุกอย่างสำหรับการสุญญากาศในอนาคต ใน Timescale เนื่องจากคุณมีชิ้นส่วน คุณจึงสามารถดรอปได้ พูดง่ายๆ ก็คือคุณบอกไฟล์ที่อยู่ในข้อมูลขนาดใหญ่ว่า “ลบ!”
Timescale เพียงเข้าใจว่าส่วนดังกล่าวไม่มีอยู่อีกต่อไป และเนื่องจากมันถูกรวมเข้ากับเครื่องมือวางแผนคิวรี จึงใช้ hooks เพื่อจับเงื่อนไขของคุณในการดำเนินการที่เลือกหรืออื่นๆ และเข้าใจทันทีว่าส่วนนี้ไม่มีอีกต่อไป - “ฉันจะไม่ไปที่นั่นอีกต่อไป!” (ไม่มีข้อมูล) นั่นคือทั้งหมด! กล่าวคือ การสแกนตารางจะถูกแทนที่ด้วยการลบไฟล์ไบนารี่ ดังนั้นจึงรวดเร็ว
NS: – เราได้สัมผัสหัวข้อที่ไม่ใช่ SQL แล้ว เท่าที่ฉันเข้าใจ Zabbix ไม่จำเป็นต้องแก้ไขข้อมูลจริงๆ และทั้งหมดนี้ก็เหมือนกับบันทึก เป็นไปได้ไหมที่จะใช้ฐานข้อมูลพิเศษที่ไม่สามารถเปลี่ยนแปลงข้อมูลได้ แต่ในขณะเดียวกันก็บันทึก สะสม และแจกจ่ายได้เร็วกว่ามาก - ตัวอย่างเช่น Clickhouse บางอย่างที่คล้ายกับ Kafka?.. Kafka ก็เป็นบันทึกเช่นกัน! เป็นไปได้ไหมที่จะรวมเข้าด้วยกัน?
เอจี: - การขนถ่ายสามารถทำได้ เรามี "คุณสมบัติ" บางอย่างตั้งแต่เวอร์ชัน 3.4: คุณสามารถเขียนไฟล์ประวัติ เหตุการณ์ และอื่นๆ ทั้งหมดลงในไฟล์ได้ แล้วส่งไปยังฐานข้อมูลอื่นโดยใช้ตัวจัดการบางตัว ในความเป็นจริง หลายคนทำงานซ้ำและเขียนลงฐานข้อมูลโดยตรง ทันที ผู้จมประวัติศาสตร์จะเขียนทั้งหมดนี้ลงในไฟล์ หมุนไฟล์เหล่านี้ และอื่นๆ และคุณสามารถถ่ายโอนสิ่งนี้ไปยัง Clickhouse ได้ ฉันไม่สามารถพูดเกี่ยวกับแผนได้ แต่บางทีการสนับสนุนเพิ่มเติมสำหรับโซลูชัน NoSQL (เช่น Clickhouse) จะดำเนินต่อไป
NS: – โดยทั่วไปปรากฎว่าคุณสามารถกำจัด postgres ได้อย่างสมบูรณ์?
เอจี: – แน่นอนว่าส่วนที่ยากที่สุดใน Zabbix คือตารางประวัติศาสตร์ที่สร้างปัญหาและเหตุการณ์มากที่สุด ในกรณีนี้หากคุณไม่จัดเก็บกิจกรรมเป็นเวลานานและจัดเก็บประวัติพร้อมแนวโน้มในพื้นที่จัดเก็บข้อมูลที่รวดเร็วอื่น ๆ โดยทั่วไปแล้วฉันคิดว่าจะไม่มีปัญหา
NS: – คุณช่วยประมาณได้ไหมว่าทุกอย่างจะทำงานได้เร็วแค่ไหนหากคุณเปลี่ยนมาใช้ Clickhouse เป็นต้น
เอจี: – ฉันยังไม่ได้ทดสอบมัน ฉันคิดว่าอย่างน้อยตัวเลขเดียวกันก็สามารถทำได้ค่อนข้างง่าย เนื่องจาก Clickhouse มีอินเทอร์เฟซของตัวเอง แต่ฉันไม่สามารถพูดได้อย่างแน่นอน ทดสอบเลยดีกว่า ทุกอย่างขึ้นอยู่กับการกำหนดค่า เช่น จำนวนโฮสต์ที่คุณมี และอื่นๆ การแทรกเป็นสิ่งหนึ่ง แต่คุณต้องดึงข้อมูลนี้ด้วย - Grafana หรืออย่างอื่น
NS: – เรากำลังพูดถึงการต่อสู้ที่เท่าเทียมกัน และไม่เกี่ยวกับข้อได้เปรียบที่ยิ่งใหญ่ของฐานข้อมูลที่รวดเร็วเหล่านี้ใช่ไหม
เอจี: – ฉันคิดว่าเมื่อเราบูรณาการจะมีการทดสอบที่แม่นยำยิ่งขึ้น
NS: – RRD เก่าๆ ดีๆ หายไปไหน? อะไรทำให้คุณเปลี่ยนมาใช้ฐานข้อมูล SQL ในตอนแรก ตัวชี้วัดทั้งหมดจะถูกรวบรวมบน RRD
เอจี: – Zabbix มี RRD ซึ่งอาจอยู่ในเวอร์ชันโบราณมาก มีฐานข้อมูล SQL อยู่เสมอซึ่งเป็นแนวทางแบบคลาสสิก แนวทางคลาสสิกคือ MySQL, PostgreSQL (มีมานานแล้ว) เราแทบไม่เคยใช้อินเทอร์เฟซทั่วไปสำหรับฐานข้อมูล SQL และ RRD
โฆษณาบางส่วน🙂
ขอบคุณที่อยู่กับเรา คุณชอบบทความของเราหรือไม่? ต้องการดูเนื้อหาที่น่าสนใจเพิ่มเติมหรือไม่ สนับสนุนเราโดยการสั่งซื้อหรือแนะนำให้เพื่อน , อะนาล็อกที่ไม่เหมือนใครของเซิร์ฟเวอร์ระดับเริ่มต้นซึ่งเราคิดค้นขึ้นเพื่อคุณ: (ใช้ได้กับ RAID1 และ RAID10 สูงสุด 24 คอร์ และสูงสุด 40GB DDR4)
Dell R730xd ถูกกว่า 2 เท่าในศูนย์ข้อมูล Equinix Tier IV ในอัมสเตอร์ดัม? ที่นี่ที่เดียวเท่านั้น ในเนเธอร์แลนด์! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - จาก $99! อ่านเกี่ยวกับ
ที่มา: will.com