Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

What is the limit on sshd connection? How much data can it process?

share|improve this question

closed as not a real question by Zoredache, Chris S, John Gardeniers, theotherreceive, splattne Aug 3 '10 at 13:01

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

The bandwidth of your connection is going to be the primary determining factor on the rate of data transfer. Otherwise, you could do some comparative testing. If you mean some limit on the total, I don't think there is one.

What is it that you're trying to do? What problem are you trying to solve?

share|improve this answer
contiguous data is sent over sshd, its taking up a lot of CPU. CPU idle goes to 0% while xfer happens Top output: last pid: 4037; load averages: 0.75, 0.40, 0.24 up 0+02:26:11 17:39:04 82 processes: 3 running, 78 sleeping, 1 zombie CPU states: 3.5% user, 32.8% nice, 59.0% system, 4.7% interrupt, 0.0% idle Mem: 212M Active, 68M Inact, 80M Wired, 451M Cache, 69M Buf, 2696M Free Swap: 2048M Total, 2048M Free PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 248 root 1 98 0 6072K 2524K select 0:24 6.69% sshd – hari Aug 3 '10 at 1:00
Your CPU (or crypto accelerator) will also limit the speed. I notice this primarily with gigabit LAN transfers. – Chris S Aug 3 '10 at 1:04

If the question you're trying to ask is "why is my SCP slow" or "how can I make SCP/SFTP transfers faster", you'll want to look into the HPN-SSH patch here:

Newer versions of OpenSSH do have larger buffers that fix some of the speed issue on high-latency high-throughput connections, but not all of it. The HPN-SSH patches also add the 'NoneSwitch' option, which allows you to encrypt the authentication but not the transfer itself. This will save keep you from bottlenecking on the CPU for high-speed transfers. Of course, you'll only want to use that switch if you don't need to encrypt the data.

Also, if you're using the -C (compression), don't. It tends to bottleneck rapidly on a single CPU over anything but a pretty slow link. If you have multiple cores, it may be worth using something like pigz (multithreaded gzipper) or tamp (multithreaded lzo.. a bit easier on the CPU than gzip).

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.