High memory allocation using SshCommand

[Levi--G]

Hi,

I noticed using SSH.Net there are a few issues using SshCommand:

• Allocation of 2kB of buffer for every command, even short ones without output and without monitoring output
• Not reading output causes these buffers to grow indefinitely for long running commands
• No way to discard this output easily
• Using sshcommands many at a time in a pool causes huge GC pressure with the many large allocations

An example from a single command running without cleaning the streams shows it allocating over 300kB of memory in a VS snapshot.

Possible solutions:

• Allocate the pipestreams only when accessed, discarding input otherwise (breaking change)
• Creating a new sshcommand that does not allocate.

I will be creating a pull request for scenario 2 as i need a solution for a project asap.

Thanks for the library!

[Levi--G]

Forgot to include the sample:

SshClient client = new SshClient(...);
client.Connect();
var c = client.RunCommand("for i in {1..1000} ; do echo aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ; done");
//300kB allocated

[Rob-Hague]

The latest develop branch has removed quite a few allocations, so you can try that. But yes, command output is buffered if not observed.

If you don't care about the output, you could do something like

Task drainOutput = cmd.OutputStream.CopyToAsync(Stream.Null);

Creating a new sshcommand that does not allocate.
I will be creating a pull request for scenario 2 as i need a solution for a project asap.

Adding another new type for a command is unlikely to be accepted. It might be better to at least flesh out a proposal if you are still convinced. I am just trying to save you from doing a lot of work that might not lead anywhere. Of course, you can do what you like in your own fork.

[Levi--G]

The latest develop branch has removed quite a few allocations, so you can try that. But yes, command output is buffered if not observed.

The example with 2kB and 300kB allocations are from the develop branch.

If you don't care about the output, you could do something like

Task drainOutput = cmd.OutputStream.CopyToAsync(Stream.Null);

This causes a thread to needlessly spin and consume the data, quite wasteful as well in my opinion.

Adding another new type for a command is unlikely to be accepted. It might be better to at least flesh out a proposal if you are still convinced. I am just trying to save you from doing a lot of work that might not lead anywhere. Of course, you can do what you like in your own fork.

Could be that it won't be accepted, i don't mind since i need it anyways, easier to have to update a fork with one class extra than having to make a new library from scratch. Current class just doesn't work for my scenario anyways. I am creating and almost done with my example of how it could be made, i'll submit it as pull request as a proposal and why i chose the approach i did, up to you to accept it or not. No hard feelings. 👍