我需要在两次服务之间传送大量mp3(Ubuntu)。
我的意思是大约一百万个文件,平均30万个文件。
我尝试过使用scp,但是大约需要一周的时间。 (大约500 KB / s)
如果我通过HTTP传输单个文件,我将获得9-10 MB / s的速度,但是我不知道如何传输所有文件。

有办法快速转移所有人吗?

评论

服务器之间有什么样的网络。我在每台计算机的1个NIC之间使用了GB以太网交叉。通过使用SCP
进行该配置,我获得了很好的结果
您可能想调查为什么scp这么慢。由于加密,它可能比ftp之类的东西要慢,但是它不应该那么慢。

我之间有100 mbps。小文件(大多数文件很小)上的scp较慢

#1 楼

我会推荐焦油。当文件树已经很相似时,rsync的性能将非常好。但是,由于rsync将对每个文件进行多次分析,然后复制更改,因此它比tar慢得多。此命令可能会执行您想要的操作。它将在机器之间复制文件,并保留权限和用户/组所有权。

tar -c /path/to/dir | ssh remote_server 'tar -xvf - -C /absolute/path/to/remotedir'


根据下面Mackintosh的注释,这是您将使用的命令用于rsync

rsync -avW -e ssh /path/to/dir/ remote_server:/path/to/remotedir


评论


+1 tar选项对于大量小文件而言效率更高,因为scp和rsync在网络上每个文件的往返行程都会更多。

– Sekenre
09年2月2日在21:16

rsync对我来说比tar更有效

– nicudotro
09年2月2日在22:24

另外,如果您有足够的CPU可用量(两端),但是(至少)主机之间的连接较慢,则值得在tar命令中启用压缩功能(gzip或bzip)。

–疫苗
2010-10-14 14:03

@Jamie:如果您使用的是ssh-agent,则应使用它。否则,只需使用“ -i”选项来指定在哪里可以找到私钥。有关详细信息,请参见手册页。

–斯科特包
2012年7月10日在17:03

@niXar仅在SSH使用终端的情况下启用〜转义字符。当您指定远程命令时,情况并非如此(除非您通过-t选项)。因此,您的关注无效。

–吉尔斯'所以-不再是邪恶的'
2013年9月18日下午14:55

#2 楼

外置硬盘和当日快递。

评论


嘿嘿...没有任何一种网络技术能胜过载有90 MPH磁带的旅行车的带宽,是吗? (昵称)我以为他在局域网上,因为他说他的HTTP速度为9-10MB /秒。

–埃文·安德森(Evan Anderson)
09年6月2日在20:01

我可以通过互联网获得这种速度,但是我住的地方很幸运!如果在局域网上,那就便宜了!

–亚当
09年2月2日在20:15

啊-没看你的位置。是的-我听说韩国的互联网连接非常壮观。卡在美国这里,我很高兴通过“网络”获得900KB /秒的速度。

–埃文·安德森(Evan Anderson)
09年6月2日在20:24

是的,但是在等待下载完成时,您可以得到美味的墨西哥卷饼,即使在首尔,也只有大约三家像样的墨西哥餐厅...

–亚当
09年2月2日在20:58

#3 楼

我会使用rsync。

如果通过HTTP导出了目录列表,则可以使用wget和--mirror参数。

已经知道HTTP比SCP快,因为SCP正在加密所有内容(从而造成CPU瓶颈)。 HTTP和rsync不会加密,因此运行速度更快。

以下是一些在Ubuntu上设置rsync的文档:https://help.ubuntu.com/community/rsync

这些文档讨论了通过SSH隧道传输rsync,但是如果您只是在不需要SSH的专用LAN上移动数据。 (我假设您在专用LAN上。如果您通过Internet获得9-10MB /秒的速度,那么我想知道您的连接方式是什么!)

这里还有其他一些连接非常基本的文档,可让您设置相对不安全的rsync服务器(不依赖SSH):http://transamrit.net/docs/rsync/

评论


尽管SCP确实使用了一些CPU来加密数据,但我认为他没有100%的CPU使用率,因此CPU并不是瓶颈。我已经太多次注意到SCP在快速转移方面效率低下。

–克里斯蒂安·丘皮图
09年6月2日在20:27

考虑到他在SCP上看到300K,在HTTP上看到9MB,我认为一个与SCP相关的瓶颈(通常是CPU)正在发挥作用。当然,可能还有其他事情。不知道有关机器的硬件规格,这很难说。

–埃文·安德森(Evan Anderson)
09年6月2日在20:36

rsync几乎肯定会使用ssh进行传输,因为这是默认行为,因此由scp加密引起的任何开销也将出现在rsync中

–丹尼尔·劳森(Daniel Lawson)
09年3月3日,0:35

“您已经看到HTTP比SCP快,因为SCP正在加密所有内容”→WRONG。除非他拥有10年的服务器,否则他不受CPU限制。

– niXar
2011年5月4日9:43



@RamazanPOLAT-您的命令行太长。以其他方式指定文件选择,它将对您很好。通常,您只需在源目录末尾指定通配符即可。您也可以使用--include和--exclude参数来获得更多细微差别。

–埃文·安德森(Evan Anderson)
2014年2月19日14:49

#4 楼

无需过多讨论,就可以使用netcat,网络瑞士刀。没有协议开销,您可以直接复制到网络套接字。
示例

srv1$ tar cfv - *mp3 | nc -w1 remote.server.net 4321

srv2$ nc -l -p 4321 |tar xfv -


评论


不幸的是,从我注意到的netcat效率来看,即使它不是应该的,它的效率也非常低。

–克里斯蒂安·丘皮图
09年6月2日在20:27

我拒绝您,因为这是非常非常糟糕的建议。有一个正确的答案:rsync。我可以列出所有更好的原因,但不适用于此页面,更不用说这个小小的注释框了。

– niXar
2011年5月4日,9:45

@niXar:如果您要做的只是一次文件传输(无需进一步同步),那么tarpipe实际上就是您所需要的。

–Witiko
13年6月14日,0:03

如果您在私有vlan和/或VPN等安全环境中进行此操作,则@niXar netcat很好。

–张怡
2013年6月25日在2:56

netcat对于安全的环境非常有用,除非您有点不习惯并且整个1TB数据流都不好。我有一个像这样的精心编写的脚本,具有并行压缩,进度输出(通过pv)和通过sha512sum进行完整性检查,但是一旦被翻转,整个流就很糟糕,因为无法恢复它。当我们需要低开销时,我们真正需要的是一种轻量级协议,例如流媒体洪流,用于我们需要低开销的东西-它将检查块(例如4MB)级别的完整性,并且在一个块出现故障时可以重新释放块。 TCP crc不够强大。

–丹尼尔·桑托斯(Daniel Santos)
19-10-9在21:36



#5 楼

如果您确实使用rsync,则有很多文件,我会尝试在两端获得版本3或更高版本。原因是较低的版本会在开始传输之前枚举每个文件。新功能称为增量递归。


现在,当rsync与另一个3.x版本进行通讯时,将使用新的增量递归算法
。这样可以使传输更快地进行传输
(在找到所有文件之前),并且需要更少的内存。
有关某些限制,请参见联机帮助页中的--recursive选项。


#6 楼

昨天在移动80 TB数据(数百万个小文件)时,从rsync切换到tar的速度被证明要快得多,因为我们停止尝试

# slow
rsync -av --progress /mnt/backups/section01/ /mnt/destination01/section01


并切换到tar而是...

# fast
cd /mnt/backups/
tar -cf - section01 | tar -xf - -C /mnt/destination01/ 


由于这些服务器位于同一LAN上,因此目标是NFS挂载在源系统上的,源系统正在执行推送。不能让它变得更快,我们决定不保留文件atime

mount -o remount,noatime /mnt/backups
mount -o remount,noatime /mnt/destination01


下图描述了从rsync到tar所做的更改的区别。这是我老板的主意,而我的同事都执行了这个主意,并在他的博客上做了精彩的文章。我只喜欢漂亮的照片。 :)



评论


我信任的一位黑客告诉我“在tc上比在nfs上运行tar甚至可能更快”。即tar cf-目录| ttcp -t dest_machine来自ftp.arl.mil/mike/ttcp.html

– Philip Durbin
2012年4月4日13:20



不相关的问题,但是该图来自何处?

–Cyber​​Jacob
2014年6月11日19:48在

#7 楼

像其他人已经推荐的rsync。如果加密产生的CPU开销是瓶颈,请使用另一种CPU占用率较低的算法,例如河豚。例如。像

rsync -ax -e 'ssh -c blowfish' /local/path user@host:/remote/path

评论


+1表示更改密码

–丹尼尔·劳森(Daniel Lawson)
09年3月3日,0:37

除非您拥有10G以太网和10年的CPU,否则CPU不会成为瓶颈。

– niXar
2011年5月4日上午10:46

只需评论:密码“ -c arcfour”的速度更快。

–Arman
2013年5月3日13:58

@niXar:但是,如果您的计算机上已经有消耗CPU的任务,那就很麻烦了。

–艾萨克
2014年12月20日上午11:44

#8 楼

复制大量文件时,我发现tar和rsync之类的工具效率不高,原因是打开和关闭许多文件的开销。在以下情况下,我编写了一个名为fast-archiver的开源工具,该工具比tar更快:https://github.com/replicon/fast-archiver;通过执行多个并发文件操作,它可以更快地运行。

这是在超过200万个文件的备份中快速存档与tar的示例;快速存档需要27分钟的存档时间,而tar则需要1小时23分钟。

$ time fast-archiver -c -o /dev/null /db/data
skipping symbolic link /db/data/pg_xlog
1008.92user 663.00system 27:38.27elapsed 100%CPU (0avgtext+0avgdata 24352maxresident)k
0inputs+0outputs (0major+1732minor)pagefaults 0swaps

$ time tar -cf - /db/data | cat > /dev/null
tar: Removing leading `/' from member names
tar: /db/data/base/16408/12445.2: file changed as we read it
tar: /db/data/base/16408/12464: file changed as we read it
32.68user 375.19system 1:23:23elapsed 8%CPU (0avgtext+0avgdata 81744maxresident)k
0inputs+0outputs (0major+5163minor)pagefaults 0swaps


要在服务器之间传输文件,您可以将ssh与快速存档一起使用,像这样:

ssh postgres@10.32.32.32 "cd /db; fast-archive -c data --exclude=data/\*.pid" | fast-archiver -x


#9 楼

我也通过netcat方法使用tar,但我更喜欢使用socat-例如,通过调整mss,可以为您的情况进行优化以提供更多功能。 (也可以根据需要笑,但是我发现socat参数更容易记住,因为它们是一致的)。所以对我来说,最近这很普遍,因为我一直在将事物转移到新服务器上:

host1$ tar cvf - filespec | socat stdin tcp4:host2:portnum

host2$ socat tcp4-listen:portnum stdout | tar xvpf -


别名是可选的。

#10 楼

另一种选择是Unison。在这种情况下,它的效率可能比Rsync略高,并且设置侦听器也更容易。

#11 楼

似乎最高答案中可能有一些错别字。这可能会更好:

tar -cf - /path/to/dir | ssh remote_server 'tar -xvf - -C /path/to/remotedir'


评论


我发现使用-f选项时命令失败。

–user11749
2012年7月20日14:22

@ user11749:该命令中有两个-f选项,这两个都是必需的。您是否在谈论将-f传递给ssh以使其进入后台?

–溯源
2012年7月26日在13:59



#12 楼



网络文件系统(NFS),然后使用您喜欢的任何文件进行复制,例如午夜指挥官(MC),鹦鹉螺(来自gnome)。我使用了NFS v3,效果很好。

Samba(CIFS),然后用您想要的任何方式复制文件,但是我不知道它的效率如何。

Evan Anderson建议的带有wget --mirror的HTTP或任何其他HTTP客户端。注意不要有任何讨厌的符号链接或误导性的索引文件。如果您只有MP3,那应该很安全。

rsync。我使用它的效果非常好,它的一个不错的功能是您可以稍后中断并继续传输。

我注意到其他人建议使用netcat。根据我的经验,我可以说与其他解决方案相比,它的速度较慢。

#13 楼

感谢Scott Pack的精彩回答(以前我不知道如何使用ssh做到这一点),我可以提供此改进(如果bash是您的shell)。这将添加并行压缩,进度指示器并检查整个网络链接的完整性:

tar c file_list |
    tee >(sha512sum >&2) |
    pv -prab |
    pigz -9 |
    ssh [user@]remote_host '
        gunzip |
        tee >(sha512sum >&2) |
        tar xC /directory/to/extract/to
    '
是用于管道的不错的进度查看器程序,而pv是并行gzip该程序默认使用与CPU一样多的线程(我相信最多8个线程)。您可以调整压缩级别以更好地适应CPU与网络带宽的比率,如果CPU的带宽远远大于带宽,则可以将其替换为pigzpxz -9e。您只需要在完成时验证两个总和是否匹配即可。

此选项对大量数据以及高延迟网络很有用,但是在链接不稳定且掉线的情况下却无济于事。在这些情况下,rsync可能是最好的选择,因为它可以恢复。

示例输出:

6c1fe5a75cc0280709a794bdfd23d7b8b655f0bbb4c320e59729c5cd952b4b1f84861b52d1eddb601259e78249d3e6618f8a1edbd20b281d6cd15f80c8593c3e  -                     ]
 176MiB [9.36MiB/s] [9.36MiB/s] [                                            <=>                                                                        ]
6c1fe5a75cc0280709a794bdfd23d7b8b655f0bbb4c320e59729c5cd952b4b1f84861b52d1eddb601259e78249d3e6618f8a1edbd20b281d6cd15f80c8593c3e  -


对于块设备:

dd if=/dev/src_device bs=1024k |
    tee >(sha512sum >&2) |
    pv -prab |
    pigz -9 |
    ssh [user@]remote_host '
        gunzip |
        tee >(sha512sum >&2) |
        dd of=/dev/src_device bs=1024k
    '


显然,请确保它们的大小或限制与count =,skip =,seek =等相同。

复制文件系统时这样,我通常会先将大多数未使用的空间pxz -d设为零,这会加快xfer的速度。

#14 楼

我认为除非安装更快的网卡,否则您不会比scp做得更好。如果您通过Internet进行此操作,那将无济于事。

我建议使用rsync。它可能没有更快的速度,但是至少如果失败了(或者因为它花费的时间太长而将其关闭),则可以在下一次中断的地方继续。

如果可以连接2直接使用千兆以太网的计算机,这可能是最快的。

评论


我之间直接有一个未使用的100mbps链接

– nicudotro
09年6月2日在20:02

不会比SCP做得更好吗? SCP正在通过加密步骤推送所有数据。 SCP将成为复制它的最慢方式之一!

–埃文·安德森(Evan Anderson)
09年6月2日在20:02

SCP对数据进行加密是正确的,但是加密速度比网络连接快几个数量级,因此可以忽略不计。

–布伦特
2009年6月3日15:37

#15 楼

对于100Mb / s,理论吞吐量为12.5 MB / s,因此在10MB / s时,您的表现还不错。

我也赞同建议通过rsh进行rsync。诸如此类:

rsync -avW -e ssh $SOURCE $USER@$REMOTE:$DEST


在100Mb / s的速度下,您的CPU应该能够处理加密/解密,而不会明显影响数据速率。而且,如果您中断了数据流,则应该能够从上次中断的地方恢复。当心,随着“数百万”个文件的启动,启动将需要一段时间才能真正传输任何内容。

#16 楼

除了我正在传输Oracle日志外,我已经遇到了这一点。

这里是故障




inefficient and encrypted (encrypted = slower than unencrypted 
depending on the link and your processor) 



rsync

efficient but typically encrypted (though not necessarily)



FTP / HTTP

both seem to be efficient, and both are plaintext. 



我使用FTP的感觉很棒成功(巨大的成功相当于Gb网络上的〜700Mb / s)。如果您获得10MB(等于80Mb / s),则可能是错误的。

您能告诉我们有关数据的来源和目的地吗?是单驱动器还是单驱动器? RAID转USB?

我知道这个问题已经有了答案,但是如果您的网络在Gb / s交叉电缆上运行缓慢,则绝对需要解决。

#17 楼

您没有提及两台计算机是否在同一LAN上,或者是否必须使用安全通道(即使用SSH),但是可以使用的另一种工具是netcat。

我将使用以下内容在接收机器上:

cd <destdir>
netcat -l -p <port> | gunzip | cpio -i -d -m


然后在发送方:

cd <srcdir>
find . -type f | cpio -o | gzip -1 | netcat <desthost> <port>


它具有以下优点:


ssh的加密没有CPU开销。
gzip -1提供轻度压缩,而不会饱和CPU,因此可以进行良好的折衷,从而提供一点压缩同时保持最大的吞吐量。 (可能对MP3数据不利,但不会造成伤害。)
如果您可以将文件分成几组,则可以并行运行两个或更多管道,并真正确保饱和网络带宽。

,例如,

find <dir1> <dir2> -type f | cpio -o | gzip -1 | netcat <desthost> <portone>
find <dir3> <dir4> -type f | cpio -o | gzip -1 | netcat <desthost> <porttwo>


注意:然后运行rsync或统一以确保一切正常。
如果愿意,可以使用tar而不是cpio
即使最终使用ssh,我也会确保它本身没有使用任何压缩,然后自己通过gzip -1进行传递,以避免CPU饱和。 (或至少将CompressionLevel设置为1。)


#18 楼

用正确的选项简单SCP将轻松达到9-10 MB / s以上LAN:


scp -C -c arcfour256 ./local/files.mp3 remoteuser@remoteserver:/opt/remote
随着/>这些选择很可能是吞吐量成为4倍或5倍比没有快选项(默认)

评论


而不是一百万个小文件。您是否尝试过自己的解决方案?

– Sajuuk
19-4-3在6:33



#19 楼

如果在src端有ftp服务器,则可以从ncftp站点使用ncftpget。它可以在内部使用tar的情况下处理小型文件。

一个比较显示了这一点:移动1.9GB的小型文件(33926个文件)


使用scp需要11m59s
使用rsync需要7分10秒
使用ncftpget需要1分20秒


#20 楼

您也可以尝试使用BBCP命令进行传输。这是一个真正尖叫的缓冲并行ssh。如果我们可以保持管道进给,通常我们可以得到90%+的线速。

$ bbcp -s 8 -w 64M -N io 'tar -cO srcdirectory' desthostname:'tar -x -C destdir'


通常,我们会尽力避免不必要地移动袖带。我们使用ZFS池,总是可以向其中添加更多的磁盘空间。但是有时候...你只需要移动东西。如果我们有一个“实时”文件系统,即使进行完全爆炸,它也可能要花费数小时(或数天)进行复制。.我们执行两步zfs发送例程:


ZFS快照,并传输到新计算机上的新池中。让它花费尽可能长的时间。
再创建一个快照,并将其作为增量发送。增量快照仅包含自第一个以来的(小得多)变更集,因此它的处理速度相对较快。
完成增量快照后,您可以翻转原始快照并切换到新副本,并且将“离线停机时间”保持在最低限度。

我们也通过BBCP发送我们的zfs转储...这可以最大程度地提高网络利用率并缩短传输时间。

BBCP是免费提供的,您可以在Google上对其进行搜索,并且它是直接的编译器。只要将其复制到src和目标计算机上的/ usr / local / bin中,它就可以正常工作。

#21 楼

我想我的回答来晚了一点,但是我在使用一台服务器上的mc(午夜指挥官)通过SFTP连接到另一台服务器上有了很好的经验。

通过FTP连接的选项位于在“左侧”和“右侧”菜单中输入以下地址:

/#ftp:name@server.xy/




/#ftp:name@ip.ad.dr.ess/


您可以像在本地文件系统上一样导航和执行文件操作。

它具有内置选项,可以在后台进行复制,但是我更喜欢使用screen命令并与mc正在复制时的屏幕(我想它的运行速度也会更快)。

#22 楼

要rsync选项的@scottpack答案

要显示上载进度,请在命令中的-avW之后使用'--progess'作为选项,如下所示。

rsync -avW --progress -e ssh /path/to/dir/ remote_server:/path/to/remotedir




#23 楼

这是一个比较一些技术的快速基准测试,


来源是4核Intel(R)Xeon(R)CPU E5-1620 @ 3.60GHz,具有250
Mbps和SATA驱动器
目标是6核Intel®Xeon(R)CPU
E-2136 @ 3.30GHz,具有1 Gbps带宽和SSD驱动器

文件数:9632,
总大小:814 MiB,
平均大小:84 KiB


RSYNC:1m40.570s
RSYNC +压缩:0m26.519s
TAR + NETCAT:1m58.763s
TAR +压缩+ NETCAT:0m28.009s

tar / netcat的命令为:

Source : tar -cf - /sourcedir/ | nc -v 11.22.33.44 5000
Dest : nc -v -l 5000 | tar -xf -


#24 楼

rsync或您可能希望将其压缩为一个文件,然后将其压缩。如果缺少磁盘空间,则可以在制作tar时直接将其通过ssh传递给管道。

#25 楼

如果您要通过MP3和其他压缩文件进行发送,则任何试图进一步压缩这些文件的解决方案都不会带来太多好处。解决方案是可以在两个服务器之间创建多个连接,从而对两个系统之间的带宽施加更大的压力。一旦达到极限,不改善硬件就无济于事。 (例如,这些服务器之间的快速网卡。)

#26 楼

我尝试了几种用于复制1GB文件的工具
结果如下:
HTTP最快,而wget -c scp最慢,而失败了次。无法恢复
rsync使用ssh作为后端,因此结果相同。
最后,我将使用wget -bqc选择http并给它一些时间。
希望这会有所帮助

评论


您是否了解http为什么最快?

– Sajuuk
19年4月3日在6:34

#27 楼

我必须将BackupPC磁盘复制到另一台计算机上。

我使用了rsync。

该计算机具有256 MB的内存。

过程我接下来是这个:


执行了没有rsync-H(花了9个小时)
rsync完成后,我同步了cpool目录并从pc目录开始;我中断了传输。
然后使用rsync标志重新启动了-H,所有在pc目录中硬链接的文件都已正确传输(该过程在cpool中找到了所有真实文件,然后链接到pc目录)(耗时3个小时) )。

最后我可以用df -m验证是否没有多余的空间。

这样,我就可以避免内存和rsync的问题。我一直都可以使用top和top验证性能,最后我传输了165GB的数据。