โพสต์รับเชิญนี้เขียนโดย Ross Dold จาก EOSphere เรียนรู้เพิ่มเติมเกี่ยวกับงานของ EOSphere ในระบบนิเวศของ EOS ที่ส่วนท้ายของบทความนี้

Antelope Leap v5.0.0 เปิดตัวเมื่อประมาณหนึ่งเดือนที่แล้ว และตอนนี้กำลังถูกนำไปใช้โดยเครือข่ายที่ใช้ Antelope จำนวนมาก เนื่องจากผู้ดำเนินการโหนดเริ่มอัปเกรดสภาพแวดล้อมการใช้งานจริงของตน

https://eosnetwork.com/zh/blog/leap-5-deployed/

Leap v5.0.0 ได้รับการออกแบบมาให้มีประสิทธิภาพ ประสิทธิผล และเชื่อถือได้มากกว่าเวอร์ชันก่อนๆ ซึ่งเป็นข่าวดีสำหรับผู้ดำเนินการโหนด เนื่องจากการปรับปรุงเล็กๆ น้อยๆ ก็สามารถแปลงเป็นกำไรมหาศาลจากโหนดฟาร์มที่ได้รับการจัดการ 100 รายการ

ด้วยเหตุนี้ ทีมงาน EOSphere จึงได้บันทึกการเปรียบเทียบเชิงปฏิบัติของการปรับปรุง CPU, หน่วยความจำ และดิสก์ IO ระหว่าง Leap v4.0.4 และ v5.0.0 ในบทความด้านล่าง

บทความต่อไปนี้เขียนขึ้นโดยอาศัยสถิติที่รวบรวมจากหนึ่งในโหนดเพียร์สาธารณะของเมนเน็ต EOSphere EOS โหนดนี้ถูกเลือกเนื่องจากมีอยู่แล้วในการใช้งานจริงและมีการใช้งานอย่างสูง โดยมีโหนดสาธารณะขาเข้าตามธรรมชาติ 180-195 โหนด การกำหนดค่าฮาร์ดแวร์มีดังนี้:

ซีพียู

ด้านล่างนี้คือแผนภูมิการใช้งาน CPU รายเดือนที่แสดงการใช้งานสำหรับเวอร์ชัน 4.0.4 ก่อนที่จะอัปเกรดเป็นเวอร์ชัน 5.0.0 ในวันที่ 22 มกราคม 2024 (20:00 น.)

การใช้งาน CPU KVM ของโหนดเพียร์สาธารณะ EOSphere

การใช้งาน CPU ลดลงทันทีจากค่าเฉลี่ย 85% เป็น 60% ปกติ นี่เป็นข่าวดีสำหรับการรันหลายโหนดในสภาพแวดล้อมทางกายภาพ เสมือน หรือคลาวด์ นอกจากนี้ยังอาจหมายความว่าขีดจำกัดเพี max-clients ที่กำหนดค่าไว้แบบดั้งเดิมที่ 200 สามารถขยายเป็น 250 หรือ 300 สำหรับโหนดสาธารณะได้

หากคุณได้อ่านบทความ Antelope chain ก่อนหน้านี้ คุณจะรู้ว่า EOSphere สนับสนุนการใช้ กลยุทธ์ tmpfs เพื่อรันโหนด Leap มาโดยตลอด

หากคุณได้อ่านบทความ Antelope chain ก่อนหน้านี้ คุณจะรู้ว่า EOSphere สนับสนุนการใช้ กลยุทธ์ tmpfs เพื่อรันโหนด Leap มาโดยตลอด

กลยุทธ์ tmpfs เกี่ยวข้องกับการเรียกใช้โฟลเดอร์ state ฐานข้อมูล nodeos chainbase ในการเมาท์ tmpfs ทำให้เราสามารถสมัคร RAM มากเกินไปผ่าน SWAP และปรับปรุงการใช้งานหน่วยความจำและประสิทธิภาพ IO ของดิสก์

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

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

Leap v5.0.0 นำเสนอโหมดการแมปฐานข้อมูลใหม่ที่เรียกว่า mapped_private เป็นทางเลือกแทนโหมด mapped เริ่มต้น แทนที่จะเขียนลงดิสก์อย่างต่อเนื่องด้วยโหมด mapped โหมด mapped_private จะใช้หน่วยความจำได้ดีขึ้นและลด IO ของดิสก์ ซึ่งทำได้โดยการแมปฐานข้อมูลไลบรารีลูกโซ่เข้ากับหน่วยความจำโดยใช้การแมปส่วนตัว ซึ่งหมายความว่าข้อมูลไลบรารีลูกโซ่ที่เข้าถึงระหว่างการดำเนินการจะถูกเก็บรักษาไว้ใน หน่วยความจำและไม่มีสิทธิ์เขียนกลับไปยังไฟล์ดิสก์ shared_memory.bin

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

การกำหนดค่า mapped_private

การกำหนดค่า mapped_private เพียงเพิ่มสิ่งต่อไปนี้ใน config.ini

> nano config.inidatabase-map-mode = mapped_private

ในการเริ่มต้นโหนด mapped_private ต้องใช้หน่วยความจำเพียงพอที่จะแทนที่การแมปส่วนตัวที่กำหนดค่าของ chain-state-db-size-mb = RAM ทางกายภาพสามารถถูกแทนที่ด้วย SWAP ที่อนุญาตให้สมัครสมาชิกเกิน

ในขณะที่เขียน RAM จริงขนาด 32GB และ SWAP ขนาด 128Gb นั้นเพียงพอที่จะเรียกใช้โหนดเมนเน็ตของ EOS

mapped_private การดำเนินงานและผลลัพธ์

เมื่อโหนดแรก mapped_private เริ่มต้น สมมติว่าคุณเริ่มจากสแน็ปช็อต ไลบรารีลูกโซ่ทั้งหมดจะถูกอัปโหลดไปยังหน่วยความจำ (RAM และ SWAP) และอาจใช้เวลาสักครู่

การใช้งาน CPU และหน่วยความจำเมื่อโหมด mapped_private เริ่มต้นเป็นครั้งแรก

เมื่อออกจากโหนด ไลบรารีลูกโซ่ในหน่วยความจำจะถูกเขียนลงดิสก์ ซึ่งอาจใช้เวลาสักครู่ขึ้นอยู่กับขนาดของไลบรารี

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

การใช้งาน CPU และหน่วยความจำของโหมด mapped_private การเริ่มต้นครั้งที่สอง

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

การใช้งานหน่วยความจำยังได้รับการปรับปรุงเล็กน้อยเมื่อเทียบกับโหมด mapped

การใช้งาน CPU และหน่วยความจำในโหมดแมป

นอกเหนือจากการสมัครใช้งาน RAM มากเกินไปและการใช้งานที่ต่ำกว่า มูลค่าที่แท้จริงของการใช้ mapped_private และเหตุผลที่ EOSphere เริ่มใช้โหมดนี้ตั้งแต่แรกก็คือ IO ของดิสก์นั้นต่ำกว่ามาก

ข้อกำหนดด้านประสิทธิภาพทำให้ผู้ปฏิบัติงานจำเป็นต้องวางโฟลเดอร์ state ที่มีฐานข้อมูล chainbase บนไดรฟ์ SSD ความเร็วสูง ไดรฟ์ SSD มีระดับความทนทานที่ผู้ผลิตกำหนด ซึ่งระบุจำนวนข้อมูลสูงสุดที่สามารถเขียนลงในไดรฟ์ได้ก่อนที่จะเกิดข้อผิดพลาด โดยทั่วไปจะวัดเป็น TerraByte Written (TBW) ซึ่งโดยทั่วไปจะอยู่ในช่วง 150–2000TBW บนดิสก์ของผู้บริโภค และในช่วง PB บนไดรฟ์ระดับองค์กร โดยพื้นฐานแล้ว การเขียนดิสก์มากเกินไปอาจทำให้ดิสก์ SSD เสื่อมสภาพ ทำให้เกิดความล้มเหลวได้

ด้านล่างนี้คือเพียร์ตัวอย่างที่ใช้โหมด mapped กับไดรฟ์ 1 ดิสก์ IO (เขียน) เครือข่ายเห็นธุรกรรม 10-15 รายการต่อวินาที (TPS)

การใช้ไดรฟ์โหมดแมป 1 ดิสก์ IO (เขียน)

นี่คือไดรฟ์ 1 ดิสก์ IO (เขียน) ของเพียร์ตัวอย่างของเรา โดยใช้โหมด mapped_private เครือข่ายจะเห็น 10-15 TPS เดียวกัน

ไดรฟ์ 1 ดิสก์ IO (เขียน) โดยใช้โหมด mapped_private

นี่แสดงให้เห็นว่าการใช้ mapped_private ช่วยลดจำนวนการเขียนได้อย่างมาก

ประมาณ 4 เมกะไบต์ (MB) ต่อวินาทีถึง 12 กิโลไบต์ (KB) ต่อวินาที ประมาณ 120TBW/ปี ลดลงเหลือ 0.378TBW/ปี

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

โดยสรุป Antelope Leap v5.0.0 มีการใช้งาน CPU ต่ำกว่า การใช้หน่วยความจำมีประสิทธิภาพมากขึ้น และจัดการ IO ดิสก์ที่ต่ำกว่าได้ง่ายขึ้นเมื่อใช้ mapped_private

อย่าลืมถามคำถามใน EOSphere Telegram และ EOS Global Telegram

โพสต์รับเชิญนี้เขียนโดย Ross Dold จาก EOSphere EOxSphere เป็นผู้ผลิตบล็อกและผู้ให้บริการโครงสร้างพื้นฐานสำหรับเมนเน็ต EOS และบล็อกเชนที่ใช้ Antelope อื่นๆ เรียนรู้เพิ่มเติมเกี่ยวกับงานของพวกเขาที่ EOSphere.io และลิงก์ด้านล่าง

เครือข่าย EOS เป็นตัวอย่างหนึ่งของยุคบล็อคเชน 3.0 ที่ขับเคลื่อนโดย EOS VM EOS VM คือกลไก WebAssembly ที่มีความหน่วงต่ำ ประสิทธิภาพสูง และปรับขนาดได้ ซึ่งสามารถบรรลุการดำเนินการธุรกรรมตามที่กำหนดด้วยประสิทธิภาพที่เกือบจะใช้งานง่าย เครือข่าย EOS ได้รับการออกแบบมาโดยเฉพาะสำหรับ Web3 และมุ่งมั่นที่จะมอบประสบการณ์ผู้ใช้และนักพัฒนา Web3 ที่ดีที่สุด EOS เป็นบล็อกเชนหลักและศูนย์กลางทางการเงินของโปรโตคอล Antelope และใช้ EOS Network Foundation (ENF) เป็นเครื่องมือสำหรับการทำงานร่วมกันแบบหลายสายโซ่และการพัฒนาผลิตภัณฑ์พื้นฐานสาธารณะ เพื่อปรับปรุงโครงสร้างพื้นฐานเพิ่มเติมและขับเคลื่อนการพัฒนาที่รวดเร็วของ EOS

EOS Network Foundation (ENF) ถือกำเนิดขึ้นเพื่อสร้างความเจริญรุ่งเรือง การกระจายอำนาจ และอนาคตสำหรับระบบนิเวศของ EOS ด้วยการส่งเสริมการมีส่วนร่วมอย่างแข็งขันของผู้มีส่วนได้ส่วนเสียในระบบนิเวศ EOS ที่สำคัญ สนับสนุนโครงการชุมชน จัดหาเงินทุนสำหรับระบบนิเวศ และสนับสนุนการสร้างระบบนิเวศเทคโนโลยีแบบเปิด ENF กำลังเริ่มต้นการเปลี่ยนแปลงรอบ Web3 รอบใหม่ ในฐานะศูนย์กลางของเครือข่าย EOS และแพลตฟอร์มโอเพ่นซอร์สชั้นนำ ENF ก่อตั้งขึ้นในปี 2564 และมีชุดเฟรมเวิร์ก เครื่องมือ และไลบรารีการปรับใช้บล็อกเชนที่มั่นคง เราร่วมกันสร้างนวัตกรรมในการสร้างชุมชนและการทำงานเพื่อสร้างอนาคตที่แข็งแกร่งสำหรับทุกคน