ตัวเลือกการบีบอัด -z พร้อมการสำรองข้อมูล rsync เร็วขึ้นหรือไม่


37

ในrsync, -zจะบีบอัดไฟล์ข้อมูลระหว่างการถ่ายโอน

ถ้าฉันเข้าใจถูกต้องให้-zบีบอัดไฟล์ก่อนถ่ายโอนแล้วแตกไฟล์หลังจากถ่ายโอน เวลาที่ลดลงระหว่างการถ่ายโอนเนื่องจากการบีบอัดมีน้ำหนักเกินกว่าเวลาสำหรับการบีบอัดและการคลายการบีบอัดหรือไม่

คำตอบสำหรับคำถามนั้นขึ้นอยู่กับว่าฉันสำรองข้อมูลไปยัง HDD ภายนอกผ่าน usb (2.0 หรือ 3.0) หรือไปยังเซิร์ฟเวอร์โดย ssh ผ่านทางอินเทอร์เน็ตหรือไม่


โปรดจำไว้ว่าหากไฟล์บีบอัดไม่ได้มีขนาดแตกต่างจากไฟล์ต้นฉบับมากนักนี่อาจเป็นค่าใช้จ่ายที่ใหญ่มาก
heemayl

1
หากต้องการเนื้อหาอย่างละเอียดในสิ่งที่ heemayl พูดหากเนื้อหาส่วนใหญ่เป็นเนื้อหาที่มีอยู่แล้วในรูปแบบการบีบอัด (jpeg, mpeg, distro แพ็คเกจ ฯลฯ ) การบีบอัดจะมีประสิทธิภาพน้อยกว่ามาก ฉันสังเกตเห็นman rsyncว่าในความเป็นจริงมีรายการส่วนต่อท้ายของไฟล์ที่จะไม่ถูกบีบอัดแม้จะมี-z(ดู--skip-compress)
goldilocks

คำตอบ:


46

มันเป็นคำถามทั่วไป การบีบอัดและคลายการบีบอัดที่จุดสิ้นสุดปรับปรุงแบนด์วิดท์ที่มีประสิทธิภาพของลิงก์หรือไม่

แบนด์วิดธ์ที่มีประสิทธิภาพ (รับรู้) ที่มีลิงก์ทำการบีบอัดและคลายการบีบอัดที่จุดสิ้นสุดเป็นหน้าที่ของ:

  1. ความเร็วในการบีบอัด (ความเร็ว CPU ของคุณ)
  2. แบนด์วิดท์ที่แท้จริงของเครือข่ายของคุณ

ฟังก์ชันอธิบายด้วยกราฟ 3 มิตินี้ซึ่งคุณอาจต้องการปรึกษาสถานการณ์เฉพาะของคุณ:

ป้อนคำอธิบายรูปภาพที่นี่

อินเตอร์เน็ตกราฟกับเครื่องมือการบีบอัดเมื่อเทียบ บทความปี 2005 โดยhttp://www.linuxjournal.com/


1
ประเภทข้อมูลของคุณก็เป็นปัจจัยสำคัญเช่นกัน (ปัจจัย # 3 หายไปจากรายการ) บทความที่เชื่อมโยงใช้การผสมผสานของข้อมูลโดยทั่วไป ของคุณอาจไม่ปกติ หากคุณกำลังซิงค์ไฟล์ ZIP 100% (หรือข้อมูลที่บีบอัดไว้ล่วงหน้า) คุณอาจไม่ต้องการบีบอัด หากคุณซิงค์ไฟล์ข้อความ 100% คุณอาจบีบอัดได้เร็วขึ้นแม้ว่าเครือข่ายของคุณจะเร็วและ CPU ของคุณช้า ชั่งน้ำหนักทั้ง 3 ปัจจัย
Richard Brightwell

13

หากคุณมีการเชื่อมต่อที่ช้ามาก (คิดว่า GPRS) คุณต้องการบีบอัดข้อมูลให้มากที่สุดเท่าที่จะทำได้มิฉะนั้นการเชื่อมต่อของคุณจะช้าลง

หากคุณมี CPU ที่ช้ามากและการเชื่อมต่อที่รวดเร็ว (เช่นอุปกรณ์เครือข่ายในตัว) คุณมักไม่ต้องการบีบอัดข้อมูลมิฉะนั้น CPU ของคุณจะช้าลง


3

ขึ้นอยู่กับความสามารถในการบีบอัดข้อมูลและพลังการประมวลผลของแหล่งที่มาและปลายทางของคุณ การสำรองข้อมูลดิสก์เต็มรูปแบบในประสบการณ์ของฉันจะบีบอัดประมาณ 30-50% ของขนาดดั้งเดิมดังนั้นจึงอาจคุ้มค่าที่จะให้ภาพ มิฉะนั้นอย่ากังวลกับการบีบอัด มันอาจจะคุ้มค่าที่จะทดสอบอัตราการบีบอัดของคุณด้วยpigz -c <your file> | wc -cและเปรียบเทียบขนาดที่คืนมากับขนาดดั้งเดิมของคุณ


2

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

การบีบอัดจะช่วยได้ก็ต่อเมื่อคุณมีผู้ส่งและตัวรับสัญญาณ rsync และเครือข่ายที่ช้ากว่านั้นในระหว่างนั้น 1Gbit อาจเร็วพอเมื่อคุณมี NAS ในพื้นที่เช่น 10Gbit นั้นมีความเร็ว SATA ดิบแล้ว การบีบอัดข้อมูลจึงจำเป็นเฉพาะเมื่อคุณมีการเชื่อมต่อ 100Mbit หรือน้อยกว่าและจะสมเหตุสมผลเมื่อข้อมูลที่ถูกบีบอัดนั้นสามารถบีบอัดได้

ฉันคิดว่า rsync อาจสังเกตเห็นว่ามันไม่ทำงานในสองเครื่อง แต่มีหนึ่งเครื่องและข้ามการบีบอัด แต่ไม่แน่ใจ


1

tl; drใช้ลิงก์ถ่ายโอนข้อมูลช้าอัดมิฉะนั้นอย่าทำเช่นนั้น ด้านล่างคือการทดสอบความเร็วในการบีบอัดลิงก์ไปยังเครื่องมือแปลงแบนด์วิดธ์และข้อมูลบางอย่าง

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

ดังนั้นลิงค์ที่ช้าที่สุดที่ฉันควรใช้การบีบอัดเพื่อรับอะไร

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

ป้อนข้อมูลจะเปลี่ยนแปลงผลของการทดสอบอย่างมาก ฉันใช้ไฟล์ปกติที่ไม่มีการบีบอัด (!) บนคอมพิวเตอร์ของฉันซึ่งอาจเป็นตัวแทนของประเภทข้อมูลที่ฉันมักจะถ่ายโอนผ่านเครือข่าย การใช้/dev/zero(สร้างศูนย์ไม่ จำกัด ) จะทำให้เข้าใจผิดเนื่องจากกระแสของเลขศูนย์จะง่ายต่อการบีบอัดและการใช้/dev/randomจะทำให้เข้าใจผิดด้วยเหตุผลตรงข้าม ดังนั้นฉันจึงใช้ไฟล์ tar ของ$HOME/localไดเรกทอรีซึ่งมีซอฟต์แวร์ที่ฉันติดตั้ง$HOMEไว้ ไฟล์นั้นไม่มีการบีบอัดในตัวเอง แต่มีการผสมผสานของไฟล์ไบนารีไฟล์บีบอัดขนาดเล็กและไฟล์ต้นฉบับ / ไฟล์ต้นฉบับและฉันจะบีบอัดไฟล์ด้วยการตั้งค่าเริ่มต้นซึ่งgzipจะลดขนาด 67% จาก 64 MiB ถึง 22 MiB

$ gzip -c local.tar | dd of=/dev/null
43092+4 records in
43093+1 records out
22063854 bytes transferred in 2.819 secs (7825741 bytes/sec)

ฉันทำเช่นนี้สองสามครั้งเพื่อรับความรู้สึกว่าค่าเฉลี่ยอาจเป็นเท่าไหร่และประมาณ 7800,000 ไบต์ต่อวินาที

จากนั้นฉันก็ใช้เครื่องคำนวณแบนด์วิดท์เครือข่ายเพื่อดูว่าสิ่งนี้เปลี่ยนเป็นอะไร ในกรณีนี้มันจะอยู่ภายใต้ความสามารถของสายเชื่อมต่อ "100Mb Ethernet" ซึ่งเร็วกว่าลิงก์อัปโหลดอินเทอร์เน็ต "ดาวน์โหลด VDSL" เร็วกว่าลิงก์ไร้สาย "802.11 [a / g]" เล็กน้อยและบางแห่ง อยู่ระหว่าง "Bluetooth v3.0" (ช้ากว่า) และ "USB 2.0" (เร็วกว่า)

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

rsyncอาจไม่ได้ใช้ไลบรารี่แบบเดียวกับที่ใช้ในgzipการบีบอัด แต่อย่างน้อยก็จะให้คำแนะนำเล็กน้อย

rsyncทำได้มากกว่าการบีบอัดอย่างที่คุณทราบและการเพิ่มความเร็วที่แท้จริงนั้นมาจากการถ่ายโอนไฟล์ [bits of] ที่มีการเปลี่ยนแปลงเท่านั้น

จากประสบการณ์ของฉันเองการใช้การบีบอัดด้วยrsyncได้กลายเป็นประโยชน์น้อยลงในช่วง 10 ปีที่ผ่านมาเนื่องจากแบนด์วิธของเครือข่ายเพิ่มขึ้น

สำหรับการสำรองข้อมูลเพิ่มเติมฉันขอแนะนำให้ตรวจสอบ--link-destตัวเลือกอย่างแน่นอน(สิ่งนี้ไม่เกี่ยวกับสิ่งที่ถ่ายโอนเฉพาะกับสิ่งที่จัดเก็บที่เป้าหมาย) นอกจากนี้หากคุณทำผ่าน SSH อย่าใช้การบีบอัดหากการเชื่อมต่อ SSH ของคุณถูกบีบอัดอยู่แล้วและบีบอัดเฉพาะการเชื่อมต่อ SSH (อุโมงค์ ฯลฯ ) ที่อยู่บนลิงก์ช้าเนื่องจากเหตุผลเดียวกับข้างต้น

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.