เหตุใด scp จึงช้าและทำให้เร็วขึ้นได้อย่างไร

59

ฉันพยายามที่จะคัดลอกชุดของไฟล์ด้วยscpแต่มันช้ามาก นี่คือตัวอย่างที่มี 10 ไฟล์:

$ time scp cap_* user@host:~/dir
cap_20151023T113018_704979707.png    100%  413KB 413.2KB/s   00:00    
cap_20151023T113019_999990226.png    100%  413KB 412.6KB/s   00:00    
cap_20151023T113020_649251955.png    100%  417KB 416.8KB/s   00:00    
cap_20151023T113021_284028464.png    100%  417KB 416.8KB/s   00:00    
cap_20151023T113021_927950468.png    100%  413KB 413.0KB/s   00:00    
cap_20151023T113022_567641507.png    100%  413KB 413.1KB/s   00:00    
cap_20151023T113023_203534753.png    100%  414KB 413.5KB/s   00:00    
cap_20151023T113023_855350640.png    100%  412KB 411.7KB/s   00:00    
cap_20151023T113024_496387641.png    100%  412KB 412.3KB/s   00:00    
cap_20151023T113025_138012848.png    100%  414KB 413.8KB/s   00:00    
cap_20151023T113025_778042791.png    100%  413KB 413.4KB/s   00:00    

real    0m43.932s
user    0m0.074s
sys 0m0.030s

สิ่งที่แปลกคืออัตราการถ่ายโอนอยู่ที่ประมาณ 413KB / s และขนาดไฟล์ประมาณ 413KB ดังนั้นจริงๆแล้วมันควรจะถ่ายโอนไฟล์หนึ่งไฟล์ต่อวินาทีอย่างไรก็ตามมันใช้เวลาประมาณ 4.3 วินาทีต่อไฟล์

ความคิดใดที่ค่าใช้จ่ายนี้มาจากไหนและมีวิธีใดที่ทำให้เร็วขึ้น?

scp time batch-jobs

— Laurent
แหล่งที่มา

3

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

— dhag

6

ดูเหมือนว่าระบบระยะไกลอาจพยายามแก้ไขที่อยู่ IP ของลูกค้าเป็นชื่อและคุณต้องรอการหมดเวลาก่อนที่เซสชันจะดำเนินการ คุณสามารถตรวจสอบการแก้ไขได้ (เช่นเพิ่มที่อยู่ IP ของคุณไปยังไฟล์ / etc / hosts ของปลายทาง)

— wurtel

4

เป็นมูลค่าการกล่าวขวัญว่าธง -C ช่วยให้การบีบอัดในระหว่างการถ่ายโอน แม้ว่าดูเหมือนว่าปัญหาของคุณจะเริ่มต้นการถ่ายโอนค่าโสหุ้ยการบีบอัดนั้นเป็น "ฟรี" และเกือบจะช่วยได้เสมอ

— แซม

@wurtel: ฉันไม่เห็นสิ่งที่คุณเห็นสิ่งที่ฉันเห็นคือเวลา ควรมีการเรียก DNS ย้อนกลับเพียงครั้งเดียวที่จำเป็น

— James K Polk

คุณพึ่ง SCP เพื่อความปลอดภัยหรือเพื่อการคัดลอกทางไกลเท่านั้น?

— Freiheit

17

@ ความคิดเห็นของ wurtel อาจถูกต้อง: มีค่าใช้จ่ายมากมายในการสร้างการเชื่อมต่อแต่ละรายการ หากคุณสามารถแก้ไขได้ว่าคุณจะได้รับการโอนเร็วขึ้น (และหากไม่สามารถทำได้ให้ใช้rsyncวิธีแก้ปัญหาของ @ roaima ) ฉันทำการทดลองถ่ายโอนไฟล์ที่มีขนาดใกล้เคียงกัน ( head -c 417K /dev/urandom > foo.1และทำสำเนาของไฟล์นั้น) ไปยังโฮสต์ที่ใช้เวลาสักครู่ในการเชื่อมต่อ (HOST4) และไฟล์ที่ตอบสนองได้อย่างรวดเร็ว (HOST1):

$ time ssh $HOST1 echo


real    0m0.146s
user    0m0.016s
sys     0m0.008s
$ time scp * $HOST1:
foo.1                                         100%  417KB 417.0KB/s   00:00    
foo.2                                         100%  417KB 417.0KB/s   00:00    
foo.3                                         100%  417KB 417.0KB/s   00:00    
foo.4                                         100%  417KB 417.0KB/s   00:00    
foo.5                                         100%  417KB 417.0KB/s   00:00    

real    0m0.337s
user    0m0.032s
sys     0m0.016s
$ time ssh $HOST4 echo


real    0m1.369s
user    0m0.020s
sys     0m0.016s
$ time scp * $HOST4:
foo.1                                         100%  417KB 417.0KB/s   00:00    
foo.2                                         100%  417KB 417.0KB/s   00:00    
foo.3                                         100%  417KB 417.0KB/s   00:00    
foo.4                                         100%  417KB 417.0KB/s   00:00    
foo.5                                         100%  417KB 417.0KB/s   00:00    

real    0m6.489s
user    0m0.052s
sys     0m0.020s
$

— drewbenn
แหล่งที่มา

1

ขอบคุณที่น่าสนใจมาก เอาต์พุต scp นั้นใช้งานไม่ได้หากแสดงในเวลาเดียวกันแม้ว่าจะแตกต่างจากโฮสต์หนึ่งไปอีกโฮสต์หนึ่งโดยสิ้นเชิง พวกเขาควรรวมเวลาการเชื่อมต่อในเวลาทั้งหมด

— เรนท์

1

ดังนั้นสมมติฐานของคุณคือทำให้การเชื่อมต่อใหม่ครั้งเดียวสำหรับแต่ละไฟล์?

— rogerdpack

59

คุณสามารถใช้rsync(เกินssh) ซึ่งใช้การเชื่อมต่อเดียวเพื่อถ่ายโอนไฟล์ต้นฉบับทั้งหมด

rsync -avP cap_* user@host:dir

หากคุณไม่ได้rsync(และทำไมไม่ !?) คุณสามารถใช้tarด้วยsshเช่นนี้ซึ่งหลีกเลี่ยงการสร้างไฟล์ชั่วคราว:

tar czf - cap_* | ssh user@host tar xvzfC - dir

rsyncคือการเป็นที่ต้องการทุกสิ่งอื่น ๆ เหมือนกันเพราะมันเป็น restartable ในกรณีที่มีการหยุดชะงัก

— roaima
แหล่งที่มา

6

คุณกำลังบอกว่าการscpเรียกใช้ครั้งเดียวจะไม่ใช้การเชื่อมต่อเดียวเพื่อถ่ายโอนไฟล์ทั้งหมดหรือไม่?

— CVN

1

ในกรณี tarpipe ไม่จำเป็นต้องมีf -ในแต่ละด้านเนื่องจาก tar ส่งออกไปยัง / อ่านจาก stdout / stdin โดยค่าเริ่มต้น ดังนั้นtar cz cap_* | ssh user@host tar xvzC dirจะทำมัน

— tremby

1

@tremby ไม่จำเป็นต้อง tarสามารถคอมไพล์ด้วยค่าเริ่มต้นที่แตกต่างกัน (ดูtar --show-defaultsถ้าคุณกำลังใช้ GNU tar หรือ/etc/default/tarเป็นอย่างอื่นและในทั้งสองกรณีอย่าลืมTAPEตัวแปรสภาพแวดล้อม)

— roaima

1

@ MichaelKjörlingเริ่มแรกฉันคิดว่าscpจะสร้างการเชื่อมต่อใหม่สำหรับแต่ละไฟล์ แต่ในความทรงจำ - และหลังจากตรวจสอบอีกครั้งด้วยtshark- ฉันรู้ว่าฉันไม่ถูกต้อง ณ จุดนี้ฉันไม่แน่ใจว่าเหตุใด OP scpจึงควรใช้เวลานานต่อไฟล์

— roaima

@roaima น่าสนใจขอบคุณ ฉันไม่เคยสังเกตเห็นว่า stdin / stdout ไม่ได้เป็นค่าเริ่มต้นจนถึงตอนนี้ BSD tar บน Mac ของฉันที่ทำงานไม่ได้พูดถึง TAPE env var ใน man page ของมันแม้ว่า GNU tar บนเครื่อง Linux ของฉันจะทำ

— tremby

15

มันคือการเจรจาการโอนที่ใช้เวลา โดยทั่วไปการดำเนินการกับไฟล์nไบต์ของbไบต์แต่ละไฟล์นั้นใช้เวลานานกว่าการดำเนินงานเดี่ยวในไฟล์เดียวไฟล์n * bไบต์มาก สิ่งนี้ก็เป็นจริงเช่นสำหรับดิสก์ I / O

หากดูอย่างระมัดระวังคุณจะเห็นว่าอัตราการถ่ายโอนในกรณีนี้คือsize_of_the_file / วินาที

หากต้องการถ่ายโอนไฟล์อย่างมีประสิทธิภาพมากขึ้นให้รวมเข้าด้วยกันtarแล้วจึงโอน tarball:

tar cvf myarchive.tar cap_20151023T*.png

หรือถ้าคุณต้องการบีบอัดไฟล์เก็บถาวร

tar cvzf myarchive.tar.gz myfile*

ว่าจะบีบอัดหรือไม่ขึ้นอยู่กับเนื้อหาของไฟล์เช่น หากเป็น JPEG หรือ PNG การบีบอัดจะไม่มีผลกระทบใด ๆ

— dr01
แหล่งที่มา

PNG ใช้การยุบและการบีบอัดข้อมูลนั้นไม่มีประโยชน์เช่นกัน

— Arthur2e5

ฉันจะบอกว่าเพราะการบีบอัดน้ำมันดินไม่มีผลลบเมื่อไฟล์ไม่สามารถบีบอัดได้อีกต่อไปมันเป็นวิธีที่ดีที่จะนำมาใส่-z

— Centimane

1

@Dave ถ้าพวกเขาไม่สามารถบีบอัดหรือเครือข่ายที่รวดเร็วก็จะช้าลง

— Davidmh

@Davidmh นี้จะเป็นจำนวนมากโดยแม้ว่า? ฉันคิดว่าการบีบอัดไฟล์ที่บีบอัดแล้วนั้นจะค่อนข้างเร็วเพราะมันจะดูว่ามันสามารถบีบอัดและพบว่ามันไม่มีอะไรเลย ขึ้นอยู่กับว่าฉันเดาว่าtarปกติจะผ่านการบีบอัดครั้งที่สองหรือถ้ามันจะทำการบีบอัดและเก็บถาวรในเวลาเดียวกัน

— Centimane

3

@Dave ในกรณีของฉัน (ข้อมูลเกี่ยวกับ HD 7000 รอบต่อนาที HD, CPU ระดับไฮเอนด์, เครือข่ายที่รวดเร็ว, ไม่โอ้อวดเลย), tar โดยไม่มีการบีบอัดจะถูกผูกไว้อย่างหมดจด IO แต่มี-zCPU ผูกไว้และช้ากว่ามาก gzip จะพยายามบีบอัดดังนั้นการชะลอตัว ท้ายที่สุดคุณไม่สามารถบอกได้ว่าสตริงไบต์สามารถบีบอัดได้จนกว่าคุณจะพยายามบีบอัด ในการตั้งค่าของฉันแม้ว่าการถ่ายโอนไฟล์ข้อความล้วน rsync โดยไม่มีการบีบอัดจะเร็วที่สุดเท่าที่ 2-3 เท่าเมื่อเทียบกับการบีบอัดที่เบาที่สุด แน่นอน YMMV

— Davidmh

6

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

HPN-SSHเป็น OpenSSH เวอร์ชันที่แพตช์ซึ่งเพิ่มขนาดของบัฟเฟอร์เหล่านี้ มันสร้างความแตกต่างอย่างมากต่อความเร็วการถ่ายโอน scp (ดูแผนภูมิในไซต์ แต่ฉันพูดจากประสบการณ์ส่วนตัวด้วย) แน่นอนเพื่อให้ได้ประโยชน์ที่คุณจะต้องติดตั้ง HPN-SSH ในโฮสต์ทั้งหมดของคุณ แต่ก็คุ้มค่าถ้าคุณต้องการถ่ายโอนไฟล์ขนาดใหญ่เป็นประจำ

— Menno Smits
แหล่งที่มา

5

ฉันใช้เทคนิคที่อธิบายไว้ที่นี่ซึ่งใช้ขนาน gzip และ netcat เพื่อบีบอัดและคัดลอกข้อมูลอย่างรวดเร็ว

มันเดือดลงไปที่:

# SOURCE: 
> tar -cf - /u02/databases/mydb/data_file-1.dbf | pigz | nc -l 8888

# TARGET:
> nc <source host> 8888 | pigz -d | tar xf - -C /

สิ่งนี้ใช้ tar เพื่อรวบรวมไฟล์หรือไฟล์ จากนั้นใช้ pigz เพื่อรับเธรด cpu จำนวนมากเพื่อบีบอัดและส่งไฟล์การส่งผ่านเครือข่ายใช้ netcat ในด้านการรับ netcat จะฟังการบีบอัด (ขนาน) และ untars

— Freiheit
แหล่งที่มา

3

ncไม่ได้เข้ารหัส เพิ่มssh -Dเวทมนตร์บางอย่างอาจ?

— Arthur2e5

นี่มันยอดเยี่ยมจริง ๆ

— Jabran Saeed

5

เพียงแค่มีปัญหานี้ทำโอนไซต์ไปยังเว็บไซต์ของไฟล์ mp4 scpขนาดใหญ่ผ่านทาง กำลังได้รับ ~ 250KB / s หลังจากปิดใช้งานการป้องกันน้ำท่วม UDP (FP) บนไฟร์วอลล์ปลายทางอัตราการถ่ายโอนเพิ่มขึ้นเป็น 6.5MB / s เมื่อเปิด FP กลับมาอัตราจะลดลงเหลือ ~ 250KB / s

ผู้ส่ง: cygwin, ผู้รับ: Fedora 20, ไฟร์วอลล์ Sophos UTM

SSH ใช้ UDP ทำอะไร @ superuser.com - ไม่ได้มาจากสิ่งที่ฉันอ่านโดยตรง

ในการตรวจสอบบันทึกของไฟร์วอลล์การตรวจจับน้ำท่วมเกิดขึ้นทั้งบนพอร์ตต้นทางและปลายทาง 4500 ผ่านที่อยู่ IP สาธารณะไม่ใช่ที่อยู่ VPN ภายในไซต์แบบส่วนตัวต่อไซต์ ดังนั้นดูเหมือนว่าปัญหาของฉันน่าจะเป็นสถานการณ์ NAT Traversal ที่scpข้อมูล TCP ถูกเข้ารหัสในที่สุดและห่อหุ้มในแพ็กเก็ต ESP & UDP และท้ายที่สุดต้องขึ้นอยู่กับ FP ในการลบออกscpจากสมการฉันรันการคัดลอกไฟล์ Windows ทั่ว VPN และสังเกตเห็นประสิทธิภาพที่คล้ายกันscpด้วยการเปิดและปิดใช้งาน FP นอกจากนี้ยังiperfทำการทดสอบผ่าน TCP และสังเกตเห็น 2Mbits / วินาทีด้วย FP และ 55Mbits / วินาทีโดยไม่ต้อง

NAT-T ทำงานกับ IPSec ได้อย่างไร @ cisco.com

— bvj
แหล่งที่มา