บางจุดที่ไม่เกี่ยวข้อง:
80K เป็นไฟล์จำนวนมาก
80,000 ไฟล์ในหนึ่งไดเรกทอรี? ระบบปฏิบัติการหรือแอพไม่สามารถจัดการกับสถานการณ์นั้นได้เป็นอย่างดี คุณเพิ่งสังเกตเห็นปัญหานี้ด้วย rsync
ตรวจสอบเวอร์ชั่น rsync ของคุณ
rsync ที่ทันสมัยจัดการกับไดเรกทอรีขนาดใหญ่ได้ดีกว่าในอดีต ตรวจสอบให้แน่ใจว่าคุณใช้เวอร์ชันล่าสุด
แม้ rsync แบบเก่าจะจัดการไดเรกทอรีขนาดใหญ่ได้ค่อนข้างดีผ่านลิงก์เวลาแฝงที่สูง ... แต่ไฟล์ 80k นั้นไม่ใหญ่ ... มันใหญ่มาก
ที่กล่าวว่าการใช้หน่วยความจำของ rsync นั้นเป็นสัดส่วนโดยตรงกับจำนวนไฟล์ในทรี ไดเรกทอรีขนาดใหญ่ใช้ RAM จำนวนมาก ความช้าอาจเกิดจากการขาดแรมทั้งสองด้าน ทำการทดสอบขณะดูการใช้งานหน่วยความจำ Linux ใช้ RAM ที่เหลืออยู่ใด ๆ เป็นดิสก์แคชดังนั้นหากคุณใช้ RAM ในระดับต่ำแสดงว่าการแคชดิสก์น้อยลง หากคุณใช้ RAM จนหมดและระบบเริ่มใช้ swap ประสิทธิภาพจะไม่ดีนัก
ตรวจสอบให้แน่ใจ - ไม่ได้ตรวจสอบการใช้งาน
--checksum(หรือ-c) ต้องอ่านแต่ละบล็อคของไฟล์ทุกไฟล์ คุณอาจจะได้รับจากพฤติกรรมเริ่มต้นเพียงแค่อ่านเวลาแก้ไข (เก็บไว้ในไอโหนด)
แบ่งงานออกเป็นชุดเล็ก ๆ
มีบางโปรเจ็กต์เช่นGigasyncซึ่งจะ "สับภาระงานโดยใช้ Perl เพื่อหักทอนไดเรกทอรีไดเรกตอรีสร้างรายการไฟล์ขนาดเล็กเพื่อถ่ายโอนด้วย rsync"
การสแกนไดเรกทอรีพิเศษจะมีค่าใช้จ่ายจำนวนมาก แต่อาจเป็นการชนะสุทธิ
ค่าเริ่มต้นของระบบปฏิบัติการไม่ได้ถูกสร้างขึ้นมาสำหรับสถานการณ์นี้
หากคุณใช้ Linux / FreeBSD / etc พร้อมค่าเริ่มต้นทั้งหมดประสิทธิภาพจะแย่สำหรับแอปพลิเคชันทั้งหมดของคุณ ค่าเริ่มต้นจะถือว่าไดเรกทอรีขนาดเล็กเพื่อไม่ให้เสีย RAM ในแคชที่มีขนาดใหญ่
ปรับแต่งระบบไฟล์ของคุณเพื่อจัดการกับไดเรกทอรีขนาดใหญ่ได้ดีขึ้น: ทำขนาดโฟลเดอร์ที่ใหญ่ขึ้นทำให้ประสิทธิภาพของ IO ช้าลงหรือไม่
ดูที่ "แคช namei"
ระบบปฏิบัติการที่คล้าย BSD มีแคชที่เร่งการค้นหาชื่อไปยัง inode ("แคช" namei ") มีแคช namei สำหรับแต่ละไดเรกทอรีหากมีขนาดเล็กเกินไปจะเป็นอุปสรรคมากกว่าการปรับให้เหมาะสม เนื่องจาก rsync กำลังทำ lstat () ในแต่ละไฟล์ inode จะถูกเข้าถึงสำหรับไฟล์ 80k ทุกไฟล์ซึ่งอาจทำให้แคชของคุณขาดหายลองศึกษาวิธีปรับแต่งประสิทธิภาพของไดเรกทอรีไฟล์ในระบบของคุณ
พิจารณาระบบไฟล์อื่น
XFS ถูกออกแบบมาเพื่อจัดการกับไดเรกทอรีที่ใหญ่กว่า ดูระบบไฟล์จำนวนมากในหนึ่งไดเรกทอรี
อาจจะเป็น 5 นาทีที่ดีที่สุดที่คุณสามารถทำได้
พิจารณาการคำนวณจำนวนดิสก์บล็อกที่กำลังอ่านและคำนวณความเร็วที่คุณควรคาดหวังว่าฮาร์ดแวร์จะสามารถอ่านบล็อกจำนวนนั้นได้
บางทีความคาดหวังของคุณสูงเกินไป พิจารณาจำนวนดิสก์บล็อกที่ต้องอ่านเพื่อทำ rsync โดยไม่มีไฟล์ที่เปลี่ยนแปลง: แต่ละเซิร์ฟเวอร์จะต้องอ่านไดเรกทอรีและอ่านหนึ่ง inode ต่อไฟล์ สมมติว่าไม่มีแคชใด ๆ เพราะไฟล์ 80k อาจทำให้คุณมีแคช สมมุติว่ามันเป็นบล็อกขนาด 80k ที่ทำให้คณิตศาสตร์ง่ายขึ้น นั่นคือข้อมูลประมาณ 40M ซึ่งควรอ่านได้ในไม่กี่วินาที อย่างไรก็ตามหากจำเป็นต้องมีดิสก์ค้นหาระหว่างแต่ละบล็อกซึ่งอาจใช้เวลานานกว่านั้นมาก
ดังนั้นคุณจะต้องอ่านดิสก์บล็อกประมาณ 80,000 บล็อก ฮาร์ดไดรฟ์ของคุณสามารถทำเช่นนั้นได้เร็วแค่ไหน? พิจารณาว่านี่เป็น I / O แบบสุ่มไม่ใช่การอ่านเชิงเส้นยาว 5 นาทีอาจยอดเยี่ยมมาก นั่นคือ 1 / (80000/600) หรือดิสก์อ่านทุก ๆ 7.5 มิลลิวินาที เร็วหรือช้าสำหรับฮาร์ดไดรฟ์ของคุณหรือไม่ มันขึ้นอยู่กับรุ่น
เปรียบเทียบกับสิ่งที่คล้ายกัน
วิธีคิดอีกอย่างคือว่านี่ หากไม่มีไฟล์ใดเปลี่ยนแปลงls -Llrกิจกรรมของดิสก์จะเท่ากัน แต่จะไม่อ่านข้อมูลไฟล์ใด ๆ เวลาที่ls -Llrใช้ในการวิ่งคือขอบเขตสูงสุดของคุณ
rsync (โดยไม่มีการเปลี่ยนแปลงไฟล์) ช้ากว่าอย่างมากls -Llrหรือไม่ จากนั้นตัวเลือกที่คุณใช้สำหรับ rsync สามารถปรับปรุงได้ อาจ-cถูกเปิดใช้งานหรือตั้งค่าสถานะอื่นที่อ่านมากกว่าไดเรกทอรีและข้อมูลเมตา (ข้อมูล inode)
rsync (โดยไม่มีการเปลี่ยนแปลงไฟล์) เกือบเร็วเท่ากับls -Llrหรือไม่ จากนั้นคุณได้ปรับ rsync ให้ดีที่สุดเท่าที่จะทำได้ คุณต้องปรับแต่งระบบปฏิบัติการเพิ่ม RAM รับไดรฟ์ที่เร็วกว่าเปลี่ยนระบบไฟล์ ฯลฯ
คุยกับ devs ของคุณ
ไฟล์ 80k เป็นเพียงการออกแบบที่ไม่ดี ระบบไฟล์และเครื่องมือระบบน้อยมากที่จัดการไดเรกทอรีขนาดใหญ่เช่นนี้ได้เป็นอย่างดี หากชื่อไฟล์เป็น abcdefg.txt ให้พิจารณาจัดเก็บไว้ใน abdc / abcdefg.txt (จดบันทึกการทำซ้ำ) สิ่งนี้จะแบ่งไดเรกทอรีออกเป็นไดเรกทอรีที่เล็กกว่า แต่ไม่ต้องการการเปลี่ยนแปลงโค้ดมากนัก
นอกจากนี้ .... พิจารณาใช้ฐานข้อมูล หากคุณมีไฟล์ 80k ในไดเรกทอรีบางทีนักพัฒนาของคุณกำลังแก้ไขข้อเท็จจริงที่ว่าสิ่งที่พวกเขาต้องการจริงๆคือฐานข้อมูล MariaDB หรือ MySQL หรือ PostgreSQL จะเป็นตัวเลือกที่ดีกว่าสำหรับการจัดเก็บข้อมูลจำนวนมาก
เฮ้เกิดอะไรขึ้นกับ 5 นาที?
สุดท้ายนี้ 5 นาทีแย่จริงๆเหรอ? หากคุณเรียกใช้การสำรองข้อมูลนี้วันละครั้ง 5 นาทีไม่ใช่เวลามาก ใช่ฉันรักความเร็ว อย่างไรก็ตามหาก 5 นาทีนั้น "ดีพอ" สำหรับลูกค้าของคุณก็จะดีพอสำหรับคุณ หากคุณไม่มี SLA เป็นลายลักษณ์อักษรคุณจะได้รับการสนทนาอย่างไม่เป็นทางการกับผู้ใช้ของคุณเพื่อดูว่าพวกเขาคาดหวังว่าการสำรองข้อมูลจะดำเนินไปอย่างรวดเร็ว
ฉันถือว่าคุณไม่ได้ถามคำถามนี้หากไม่จำเป็นต้องปรับปรุงประสิทธิภาพ อย่างไรก็ตามหากลูกค้าของคุณมีความสุขกับ 5 นาทีประกาศชัยชนะและไปยังโครงการอื่น ๆ ที่ต้องการความพยายามของคุณ
อัปเดต:หลังจากการสนทนาเราได้พิจารณาแล้วว่าคอขวดเป็นเครือข่าย ฉันจะแนะนำ 2 อย่างก่อนที่จะยอมแพ้ :-)
- ลองบีบแบนด์วิดท์ออกจากการบีบอัดให้มากขึ้น อย่างไรก็ตามการบีบอัดต้องการ CPU มากกว่าดังนั้นหาก CPU ของคุณโอเวอร์โหลดอาจทำให้ประสิทธิภาพแย่ลง ลอง rsync ด้วยและไม่ใช้
-zและกำหนดค่า ssh ด้วยและไม่บีบอัด ใช้เวลาทั้ง 4 ชุดเพื่อดูว่าชุดค่าผสมชุดใดมีประสิทธิภาพดีกว่าชุดอื่น ๆ หรือไม่
- รับชมเครือข่ายเพื่อดูว่ามีการหยุดชั่วคราวหรือไม่ หากมีการหยุดชั่วคราวคุณสามารถค้นหาสิ่งที่ทำให้พวกเขาและเพิ่มประสิทธิภาพที่นั่น หาก rsync ส่งอยู่เสมอแสดงว่าคุณถึงขีด จำกัด แล้ว ทางเลือกของคุณคือ:
- เครือข่ายที่เร็วขึ้น
- อย่างอื่นที่ไม่ใช่ rsync
- ย้ายต้นทางและปลายทางเข้าหากันมากขึ้น หากคุณไม่สามารถทำเช่นนั้นคุณสามารถ rsync กับเครื่องท้องถิ่นแล้ว rsync ไปยังปลายทางจริงหรือไม่ อาจมีประโยชน์ในการทำเช่นนี้หากระบบต้องหยุดทำงานในระหว่างการเริ่มต้น rsync