Everything Janne says in his answer is a great idea, but there are a few things it might be worth checking first; specifically, that the network path between the two servers is unblocked.
What does your netstat -in
output say? Are there TX or RX errors on the two NICs involved (one or two are OK, but literally, anything over about 10 is cause for concern)? If so, there may be duplex issues; you will need to work with your network admin to sort those out.
Can you test simple throughput with (eg) nc
? If you open up a listener on one server with nc -l 12345 > /dev/null
then throw ten gig of data at it from the other, with dd if=/dev/zero bs=1000k count=10000 | time nc a.b.c.d 12345
(where a.b.c.d
is the ip address of the listening server), how long does that take? For a 100Mb network, that should take on the order of 850s (about 15 mins); for 1Gb or 10Gb networks, divide accordingly. If it's much slower than that, again, you must suspect an issue at a lower level than the protocol.
If there are fundamental networking issues on the path, no protocol on earth will make things better.
Edit: I've added to this in the light of voretaq7's comment above, that the machines might be at different sites. If that's so, then you might have no problem at all other than limited bandwidth between the sites.
An example: I have two servers, at sites connected to the internet by 4Mb/s connections, where the powers that be wanted to copy a 1.5TB production database from one site to the other. I pointed out that, even if they got perfect connectivity between the two sites, and neither internet connection was used for anything other than this copy (both ropey assumptions), it would take about 35 days to copy the data. They agreed to buy me a fast desktop USB RAID box, and I moved the data by London Underground.
If this is the issue, there is no fix except to pay for more bandwidth (or do it via sneakernet/tubenet, as I did). If the two machines are directly connected via a LAN, this caveat does not apply.