ทำไม rsync เร็วกว่า NFS

ไม่กี่วันที่ผ่านมาฉันสังเกตเห็นบางสิ่งที่ค่อนข้างแปลก (อย่างน้อยสำหรับฉัน) ฉันวิ่ง rsync คัดลอกข้อมูลเดียวกันและลบหลังจากนั้นก็จะ NFS /nfs_mount/TESTติดที่เรียกว่า นี้/nfs_mount/TESTจะเป็นเจ้าภาพ / nfs_server-eth1ส่งออกจาก MTU บนเน็ตเวิร์กอินเตอร์เฟสทั้งสองคือ 9000 สวิตช์ในระหว่างรองรับเฟรมขนาดใหญ่เช่นกัน ถ้าฉันจะrsync -av dir /nfs_mount/TEST/ได้รับความเร็วการถ่ายโอนเครือข่าย X MBps ถ้าฉันจะrsync -av dir nfs_server-eth1:/nfs_mount/TEST/ได้รับความเร็วการถ่ายโอนเครือข่ายอย่างน้อย 2X MBps NFS nfs rw,nodev,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountvers=3,mountproto=tcpของฉันติดตัวเลือก

Bottom line: การถ่ายโอนทั้งสองผ่านเครือข่ายย่อยเดียวกัน, สายไฟเดียวกัน, อินเทอร์เฟซเดียวกัน, อ่านข้อมูลเดียวกัน, เขียนไปยังไดเรกทอรีเดียวกัน, เป็นต้นความแตกต่างเพียงอย่างเดียวคือผ่าน NFSv3, อีกอันหนึ่งผ่าน rsync

ไคลเอนต์คือ Ubuntu 10.04, เซิร์ฟเวอร์ Ubuntu 9.10

ทำไม rsync ถึงเร็วขนาดนี้? วิธีทำให้ NFS ตรงกับความเร็วนั้น?

ขอบคุณ

แก้ไข: โปรดทราบว่าฉันใช้ rsync เพื่อเขียนไปยังการแบ่งปัน NFS หรือ SSH ลงในเซิร์ฟเวอร์ NFS และเขียนในเครื่องที่นั่น ทั้งสองครั้งที่ฉันrsync -avเริ่มต้นด้วยไดเรกทอรีปลายทางที่ชัดเจน พรุ่งนี้ฉันจะลองทำสำเนาธรรมดา

แก้ไข 2 (ข้อมูลเพิ่มเติม): ขนาดไฟล์มีตั้งแต่ 1KB-15MB ไฟล์ถูกบีบอัดอยู่แล้วฉันพยายามที่จะบีบอัดมันต่อไปโดยไม่ประสบความสำเร็จ ฉันทำไฟล์จากที่tar.gz dirนี่คือรูปแบบ:

• rsync -av dir /nfs_mount/TEST/ = การถ่ายโอนที่ช้าที่สุด;
• rsync -av dir nfs_server-eth1:/nfs_mount/TEST/= rsync ที่เร็วที่สุดที่เปิดใช้งานเฟรมขนาดใหญ่; โดยไม่ต้องมีเฟรมจัมโบ้ช้ากว่าเล็กน้อย แต่ก็ยังเร็วกว่าเฟรมโดยตรงไปยัง NFS อย่างมีนัยสำคัญ
• rsync -av dir.tar.gz nfs_server-eth1:/nfs_mount/TEST/ = เกี่ยวกับสิ่งเดียวกันกับที่ไม่ใช่ tar.gz

ทดสอบด้วยcpและscp:

• cp -r dir /nfs_mount/TEST/= เร็วกว่าเล็กน้อยrsync -av dir /nfs_mount/TEST/แต่ก็ยังช้ากว่าrsync -av dir nfs_server-eth1:/nfs_mount/TEST/อย่างมาก
• scp -r dir /nfs_mount/TEST/= โดยรวมที่เร็วที่สุดเอาชนะได้เล็กน้อยrsync -av dir nfs_server-eth1:/nfs_mount/TEST/;
• scp -r dir.tar.gz /nfs_mount/TEST/ = เกี่ยวกับสิ่งเดียวกันกับที่ไม่ใช่ tar.gz

ข้อสรุปอิงจากผลลัพธ์นี้: สำหรับการทดสอบนี้ไม่มีความแตกต่างอย่างมีนัยสำคัญหากใช้ tar.gz ไฟล์ขนาดใหญ่หรือขนาดเล็กจำนวนมาก การเปิดหรือปิดเฟรมจัมโบ้นั้นแทบไม่ต่างกันเลย cpและscpเร็วกว่าสิ่งที่rsync -avเทียบเท่า การเขียนลงใน NFS ที่ส่งออกโดยตรงนั้นช้ากว่าอย่างมาก (อย่างน้อย 2 เท่า) มากกว่าการเขียนไปยังไดเรกทอรีเดียวกันบน SSH โดยไม่คำนึงถึงวิธีการที่ใช้

ความแตกต่างระหว่างcpและrsyncไม่เกี่ยวข้องในกรณีนี้ ฉันตัดสินใจที่จะลองcpและscpเพียงเพื่อดูว่าพวกเขาแสดงรูปแบบเดียวกันและพวกเขาทำ - ความแตกต่าง 2X

ตามที่ฉันใช้rsyncหรือcpในทั้งสองกรณีฉันไม่สามารถเข้าใจได้ว่าอะไรที่ป้องกันไม่ให้ NFS เข้าถึงความเร็วการถ่ายโอนของคำสั่งเดียวกันผ่าน SSH

ทำไมการเขียนถึงการแชร์ NFS จึงช้ากว่าการเขียนที่เดียวกันถึง SSH ถึง 2 เท่า?

(ตัวเลือก NFS เซิร์ฟเวอร์ / etc / ส่งออก) rw,no_root_squash,no_subtree_check,syncEdit3: ของลูกค้า / proc / nfs rw,nodev,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountvers=3,mountproto=tcpเมาท์แสดง:

ขอบคุณทุกคน!

อาจไม่ใช่ความเร็วในการถ่ายโอนที่ช้าลง แต่เพิ่มความล่าช้าในการเขียน ลองติดตั้ง NFS แชร์ async แทนการซิงค์และดูว่าปิดช่องว่างความเร็วหรือไม่ เมื่อคุณ rsync ผ่าน ssh กระบวนการ rsync ระยะไกลจะเขียนแบบอะซิงโครนัส (เร็ว) แต่เมื่อเขียนไปยังการแชร์ nfs ที่ติดตั้งแบบซิงโครนัสการเขียนจะไม่ได้รับการยืนยันในทันที: เซิร์ฟเวอร์ NFS รอจนกระทั่งพวกเขากดดิสก์ (หรือมีแนวโน้มว่าแคชคอนโทรลเลอร์) มากกว่าก่อนที่จะส่งการยืนยันไปยังไคลเอนต์ NFS

หาก 'async' แก้ไขปัญหาของคุณโปรดทราบว่าหากมีสิ่งใดเกิดขึ้นกับเซิร์ฟเวอร์ NFS เขียนทับกลางคันคุณอาจจบลงด้วยข้อมูลที่ไม่สอดคล้องกันบนดิสก์ ตราบใดที่การติดตั้ง NFS นี้ไม่ใช่ที่เก็บข้อมูลหลักสำหรับข้อมูลนี้ (หรืออื่น ๆ ) คุณก็อาจจะใช้ได้ แน่นอนว่าคุณต้องอยู่ในเรือลำเดียวกันหากคุณดึงปลั๊กบนเซิร์ฟเวอร์ nfs ระหว่าง / หลัง rsync-over-ssh (เช่น rsync กลับมาเป็น 'เสร็จสิ้น' เซิร์ฟเวอร์ล้มเหลวของ nfs ข้อมูลที่ปราศจากข้อผูกมัดในแคชการเขียนจะหายไป ปล่อยให้ข้อมูลไม่สอดคล้องกันบนดิสก์)

แม้ว่าจะไม่ใช่ปัญหาในการทดสอบของคุณ (การซิงค์ข้อมูลใหม่) โปรดทราบว่า rsync บน ssh สามารถสร้างความต้องการ CPU และ IO อย่างมีนัยสำคัญบนเซิร์ฟเวอร์ระยะไกลก่อนที่จะถ่ายโอนไบต์เดียวในขณะที่ทำการคำนวณ checksums และสร้างรายการไฟล์ที่จำเป็น อัปเดต

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

สิ่งนี้จะช่วยได้: http://en.wikipedia.org/wiki/Rsync

Rsync เป็นโปรโตคอลไฟล์ที่ถ่ายโอนเฉพาะบิตที่เปลี่ยนแปลงระหว่างไฟล์ NFS เป็นโปรโตคอลไฟล์ไดเรกทอรีระยะไกลที่จัดการทุกอย่างทุกครั้ง ... เหมือน SMB ในทางใดทางหนึ่ง ทั้งสองมีความแตกต่างและเพื่อจุดประสงค์ที่แตกต่างกัน คุณสามารถใช้ Rsync เพื่อถ่ายโอนระหว่างการแบ่งปัน NFS สองรายการ

สิ่งนี้น่าสนใจ ความเป็นไปได้ที่คุณอาจไม่ได้พิจารณาคือเนื้อหา / ประเภทของไฟล์ที่คุณกำลังส่ง

หากคุณมีไฟล์เล็ก ๆ น้อย ๆ (เช่นอีเมลในแต่ละไฟล์) ประสิทธิภาพของ NFS อาจจะมีการใช้งานเนื่องจากไม่ใช้ MTU เต็มรูปแบบ (อาจเป็นไปได้ว่า TCP / UDP อาจน้อยกว่า)

อีกทางหนึ่งถ้าคุณมีไฟล์ / ข้อมูลที่บีบอัดได้สูงซีพียูเร็วและเครือข่ายที่ไม่มีความเร็วของ CPU (*) คุณจะได้รับความเร็วมากขึ้นจากการบีบอัดโดยนัยผ่านลิงก์ ssh

ความเป็นไปได้ที่สามคือไฟล์ (หรือหนึ่งเวอร์ชัน) มีอยู่ในปลายทางแล้ว ในกรณีนี้การเร่งความเร็วจะเป็นเพราะโปรโตคอล rsync ช่วยให้คุณถ่ายโอนไฟล์

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

ฉันยังใช้ -e "ssh Ciphers = arcfour" เพื่อเพิ่มปริมาณงาน

หากเป้าหมายของคุณคือเพียงแค่คัดลอกไฟล์ทั้งหมดจากที่หนึ่งไปอีกที่หนึ่งแล้ว tar / netcat จะเป็นตัวเลือกที่เร็วที่สุด หากคุณรู้ว่าคุณมีช่องว่างมากมายในไฟล์ (ศูนย์) ให้ใช้ตัวเลือก -i

แหล่งที่มา: tar cvif - / path / to / source | nc DESTINATION PORTNUM จุดหมายปลายทาง: cd / path / to / source && nc -l PORTNUM | tar xvif -

หากคุณรู้ว่าข้อมูลของคุณสามารถบีบอัดได้ให้ใช้การบีบอัดคำสั่ง tar ของคุณ -z -j -Ipixz

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

แหล่งที่มา: tar cvif - / path / to / source | pixz -2 -p12 | nc DESTINATION PORTNUM # tar, ละเว้นค่าศูนย์, การบีบอัดระดับ 2 pixz โดยใช้ 12 cpu cores DESTINATION: nc -l PORTNUM | tar -Ipixz -xvif

หากคุณปรับระดับการบีบอัดและแกนประมวลผลให้ถูกต้องทั้งนี้ขึ้นอยู่กับชุดข้อมูลของคุณคุณควรจะให้เครือข่ายใกล้เคียงกับความอิ่มตัวและทำการบีบอัดให้เพียงพอที่คุณจะเกิดปัญหาคอขวดกลายเป็นดิสก์ เหมือน).

สำหรับ rsync ฉันเชื่อว่ามันข้ามศูนย์แบบเดียวกับที่ tar ทำกับตัวเลือกนั้นดังนั้นมันจึงส่งข้อมูลน้อยกว่า NFS NFS ไม่สามารถตั้งสมมติฐานเกี่ยวกับข้อมูลได้ดังนั้นจึงต้องส่งทุกไบต์พร้อมกับโอเวอร์เฮดโปรโตคอล NFS rsync มีค่าใช้จ่ายบางส่วน ..

netcat ไม่มีเลย .. มันจะส่งแพ็คเก็ต TCP แบบเต็มซึ่งไม่มีอะไรเลยนอกจากข้อมูลที่คุณสนใจ

ด้วย netcat เช่นเดียวกับ scp คุณต้องส่งแหล่งข้อมูลทั้งหมดตลอดเวลาคุณไม่สามารถเลือกได้เช่นเดียวกับ rsync ดังนั้นจึงไม่เหมาะสำหรับการสำรองข้อมูลที่เพิ่มขึ้นหรือสิ่งอื่น ๆ แต่เป็นการดีสำหรับการคัดลอกข้อมูลหรือการเก็บถาวร

คุณมีการตั้งค่าการล็อคไฟล์บน nfsshare หรือไม่? คุณอาจได้รับ preformance มากขึ้นถ้าปิดใช้งาน

ฉันคิดว่าความเร็วที่เพิ่มขึ้นอย่างน้อยส่วนหนึ่งเป็นเพราะ "rsync src host: / path" ที่วางไข่กระบวนการท้องถิ่นบนเครื่องระยะไกลสำหรับการส่ง / รับซึ่งจะลด I / O ของคุณครึ่งหนึ่งได้อย่างมีประสิทธิภาพ