ความคงอยู่ของ Redis RDB ทำงานเบื้องหลังได้อย่างไร

ฉันกำลังผ่านการเพียรพยายามของ Redis RDB ฉันมีข้อสงสัยบางประการเกี่ยวกับการคงอยู่ของ RDB ที่เกี่ยวข้องกับข้อเสียของมัน

ความเข้าใจจนถึงตอนนี้:

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

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

อ้างอิงจากเอกสารประกอบ

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

ฉันรู้ว่า fork ทำงานอย่างไรตามความรู้ของฉัน เมื่อ fork กระบวนการหลักจะสร้างกระบวนการลูกใหม่และเราสามารถอนุญาตให้โค้ดบางส่วนที่กระบวนการลูกจะดำเนินการตาม pid ของมันหรือเราสามารถจัดเตรียมไฟล์ปฏิบัติการใหม่ที่จะใช้งานได้โดยใช้ exec( ) การเรียกของระบบ

แต่สิ่งที่ฉันไม่เข้าใจจะหนักแค่ไหนเมื่อชุดข้อมูลใหญ่ขึ้น?

ฉันคิดว่าฉันรู้คำตอบ แต่ฉันไม่แน่ใจเกี่ยวกับเรื่องนั้น

อ้างอิงจากลิงก์นี้ https://www.bottomupcs.com/fork_and_exec.xhtml

เมื่อกระบวนการเรียกทางแยกแล้ว

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

ตามคำสั่งข้างต้น ชุดข้อมูลทั้งหมดของ Redis จะถูกคัดลอกไปยังรายการย่อย

ฉันเข้าใจถูกไหม?


person Thinker    schedule 06.10.2017    source แหล่งที่มา
comment
โดยส่วนตัวแล้วฉันชอบวิธี AOF มากกว่า วิธีนี้มีความคงทนและเร็วกว่า สำหรับประสบการณ์ของฉันทั้งสองวิธีต้องใช้หน่วยความจำ x2 แต่วิธี RDB ต้องการ IO ถึง HD มากกว่า ดังนั้นหาก DB ของคุณใหญ่ก็จะต้องใช้เวลา...   -  person h0x91B    schedule 06.10.2017
comment
ฉันได้ตอบไปแล้วว่าทำไม fork จึงช้า และเหตุใดการบันทึก rdb จึงช้า แต่คุณอาจต้องการทำให้คำถามของคุณเฉพาะเจาะจงมากขึ้นและไม่เป็นระเบียบน้อยลง และอัปเดตชื่อคำถามของคุณ   -  person nnog    schedule 06.10.2017


คำตอบ (1)


เมื่อ Standard Fork ถูกเรียกด้วยการ Copy-on-write ระบบปฏิบัติการจะต้องคัดลอกรายการตารางเพจทั้งหมด ซึ่งอาจต้องใช้เวลาหากคุณมีเพจขนาดเล็กขนาด 4,000 หน้าและชุดข้อมูลขนาดใหญ่ นี่คือสิ่งที่ทำให้เวลา fork() จริงช้าลง

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

อ่านเพิ่มเติม:

การฟอร์กกระบวนการขนาดใหญ่บน Linux เร็วขึ้นหรือไม่

http://kirkwylie.blogspot.co.uk/2008/11/linux-fork-Performance-redux-large.html

person nnog    schedule 06.10.2017