scp vs rcp
Kerti
I am trying to replace rcp command in some scripts that do overnight
transfer of large database files from one server to another.Both
servers run Solaris 2.6 on SPARC and have SSH 3.2.5 non commercial
version installed.
Everything seems to be working fine,except the fact that the
transfer takes roughly one hour when done with rcp and more than four
hours (!) when
done with scp.
I tried transfering files manually with same results: rcp is four
times faster
than scp,so I have no doubts that my simple file transfer script is
not the culprit.
Is scp inherently slower than rcp and can anything at all be done to
speed up
scp?
Thanks a lot,
Kerti Varoshazi
Nico Kadel-Garcia
> Hi all,
> I am trying to replace rcp command in some scripts that do overnight
> transfer of large database files from one server to another.Both
> servers run Solaris 2.6 on SPARC and have SSH 3.2.5 non commercial
> version installed.
> Everything seems to be working fine,except the fact that the
> transfer takes roughly one hour when done with rcp and more than four
> hours (!) when
> done with scp.
Try using "rsync -e ssh" or configure rsync to allow access to a
specific directories files only from a specific machine: only duplicate
the files if you have to, otherwise leave them untouched.
> I tried transfering files manually with same results: rcp is four
> times faster
> than scp,so I have no doubts that my simple file transfer script is
> not the culprit.
Sounds like your machines are under-powered or over-loaded: SSH does in
fact require a significant bandwidth load.
Are these a lot of teeny little files, or big files? Would you benefit
from using "tar cf - files | ssh -l root target-machine tar xf -" syntax
to make the transfer more efficient?
> Is scp inherently slower than rcp and can anything at all be done to
> speed up
> scp?
See above.
David Magda
[...]
> Is scp inherently slower than rcp and can anything at all be done
> to speed up scp?
Well the encryption would slow things down a bit. What type of
hardware is this on?
--
David Magda <dmagda at ee.ryerson.ca>, http://www.magda.ca/
Because the innovator has for enemies all those who have done well under
the old conditions, and lukewarm defenders in those who may do well
under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI
Kerti
These are big files,from several hundered Mb to more than 1Gb each
so doing tar would not speedup the process,I'm affraid.
If the load on machines is a problem for scp,wouldn't it be the
problem for rcp too?
I am closely watching I/O throughput,memory and CPU usage and
values seem pretty low indeed.
Two servers in questuion are E-4500 with 8 CPUs and 4Gb of memory
and E-450 with 2 CPUs and 2Gb of memory.
dkol...@attbi.com
I ran into the same issue. scp is, in fact, significantly slower
than rcp. Using the standard load, I was copying Oracle archive
logs at roughly 1/4 the speed of rcp. You can get different
performance using different encryption algorithms; however, even
with that, I was only able to get to 50% throughput of rcp.
Fortunately, the files I was transferring were large numbers of
smaller files. I ended up writing a perl script that multiplexed
the scp of files. The end result was the scp process actually had
better throughput than the rcp when the database was under a
significant load (kicking out archive logs every 2-3 minutes).
While the rcp process would copy one archive log at a time, the scp
process would copy up to 15 simultaneously. Worked pretty cool.
I don't know if something similar would work for your environment
HTH;
Doug
--------
Senior UNIX Admin
O'Leary Computer Enterprises
dkol...@attbi.com (w) 630-904-6098 (c) 630-248-2749
resume: http://home.attbi.com/~dkoleary/resume.html
David Magda
> I ran into the same issue. scp is, in fact, significantly slower
> than rcp. Using the standard load, I was copying Oracle archive
> logs at roughly 1/4 the speed of rcp. You can get different
> performance using different encryption algorithms; however, even
> with that, I was only able to get to 50% throughput of rcp.
[...]
Is it inherent in scp(1) or SSH in general? Would using tar(1) or
cpio(1) and then piping through ssh(1) to the other side a
possibility for the OP?
I used such a mechanism for transferring a huge directory structure
(10+GB, 100+ direcotories, 300+ files) and it work pretty well. It
went from one Sun Netra 1400 to another, and a got a rough transfer
rate of about 200KB/s (a little higher but I use that number for
transfer time estimates). NFS was another possibility but it entailed
editing dfstab files, etc. and this solution was more straightword.
Jacob Nevins
>Nico Kadel-Garcia <nka...@comcast.net> wrote in message
>news:<yYSdnSjpHu4...@comcast.com>...
>> Kerti wrote:
>>> I am trying to replace rcp command in some scripts that do overnight
>>> transfer of large database files from one server to another.Both
>>> servers run Solaris 2.6 on SPARC and have SSH 3.2.5 non commercial
>>> version installed.
>>> Everything seems to be working fine,except the fact that the
>>> transfer takes roughly one hour when done with rcp and more than four
>>> hours (!) when done with scp.
>>> times faster than scp,so I have no doubts that my simple file transfer
>>> script is not the culprit.
> I am closely watching I/O throughput,memory and CPU usage and
> values seem pretty low indeed.
> Two servers in questuion are E-4500 with 8 CPUs and 4Gb of memory
> and E-450 with 2 CPUs and 2Gb of memory.
Many old implementations of the SFTP protocol were implemented in a
naive way which made poor use of available bandwidth. Newer versions
tend to make more efficient use of bandwidth; I think this is true of
most implementations these days. So it might be worth upgrading your
implementation (I believe it's the client version which is
significant).
(There is further scope for confusion here because there is both a
protocol called `scp', and (in many implementations) also a command
called `scp', and the `scp' command doesn't necessarily use the `scp'
protocol; it may use the newer SFTP protocol.)
Your observation of low CPU and I/O usage is consistent with this
being the problem. Elsewhere in the thread it's been reported that
running several instances of `scp' in parallel makes efficient use of
bandwidth, which is also consistent with this.
I couldn't say whether any of this applies in your situation, as I
don't know when the various implementations improved their use of
bandwidth in SFTP. I can only speak for PSCP/PSFTP, which were only
fixed very recently (see
<http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/sftp-slow.html>).
dkol...@attbi.com
> dkol...@attbi.com writes:
> Is it inherent in scp(1) or SSH in general? Would using tar(1) or
> cpio(1) and then piping through ssh(1) to the other side a
> possibility for the OP?
I was using a recent version of F-secure - can't remember the exact
version, but it wasn't more than 1 minor iteration out of date.
After my tweaking exercise, I ended up calling the vendor. They
appeared to be surprised at my throughput.
Based on that, I'm assuming its inherent in ssh. Encryption isn't
a lightweight function; I would imagine it'd be slower...
David Magda
[...]
> Based on that, I'm assuming its inherent in ssh. Encryption isn't
> a lightweight function; I would imagine it'd be slower...
True, but the OP mentioned in this thread someplace that both CPU and
disk usage was low. If the slowdown was from encryption, wouldn't it
be seen in the fact that one (or more) of the CPUs was pegged?
dkol...@attbi.com
> True, but the OP mentioned in this thread someplace that both CPU and
> disk usage was low. If the slowdown was from encryption, wouldn't it
> be seen in the fact that one (or more) of the CPUs was pegged?
Probably, but not necessarily. I could write a program that seemingly
does a lot of stuff but also has a lot of sleep states built in, as an
example. That would end up taking a long time but still not completely
tap any cpu. Granted, that's not very likely, particularly in this case,
but it is still possible.
I'm not sure what the root cause is; just seems to be a fact. I'll leave
it to the mathmenticians to figure out the root cause.
Darren Tucker
David Magda <dmagda+tr...@ee.ryerson.ca> wrote:
[about tar + ssh]
>I used such a mechanism for transferring a huge directory structure
>(10+GB, 100+ direcotories, 300+ files) and it work pretty well. It
>went from one Sun Netra 1400 to another, and a got a rough transfer
>rate of about 200KB/s (a little higher but I use that number for
>transfer time estimates).
That rate (200 KB/s) seems low to me. I just did a test with my somewhat
loaded 170MHz SparcStation 5 on a 10Mbit/s hub, to and from a Linux box
(900MHz VIA, 2 LAN hops away). I copied a 30MB compressed Linux kernel
tarball, using the aes-128 cipher.
To and from the SS5, I get these numbers reported by scp/sftp:
scp to 39 sec (718.7KB/s), from 41 sec (660.7KB/s)
sftp to 42 sec (664.0KB/s), from 48 sec (582.2KB/s)
tar+ssh to and from both took 43 sec
If you're looking to improve your speed, I'd try:
* Use a fast cipher (eg AES or blowfish, 3des is particularly slow)
* Experiment with and without compression. Depending on your data and
CPU/bandwidth availability, this can make a big difference either way.
* Recompile OpenSSL and OpenSSH with optimization for your CPU (eg gcc
-mv8 or -mv9). This can make a big difference too.
--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.