I’m using ssh port forwarding through a one-CPU Mikrotik (usually a 751U-2HnD) to access VNC servers at the remote end.
The client isn’t busy. The server isn’t busy. But, the poor CPU on the Mikrotik spikes to the point where occasionally it bogs down, resets.
Has anyone else seen this sort of thing with ssh port forwarding? Is there maybe a way to “re-nice” a given sshd session?
There is no way to give less CPU to the ssh process, but you should be able to throttle the bandwidth from the VNC server using a queue - which creates an additional CPU load as it has to handle the queueing but the benefit should prevail (after all it depends on how much you reduce the available bandwidth). The question is whether in this case the VNC screen refresh speed will be bearable for the user; the same question would remain if you managed to give less CPU to the ssh process.
Strangely enough, my solution was to apply ssh compression to an already-compressed (Tight)VNC protocol. ssh -C has provided worlds of stability! I’m no longer worried about crashing the Mikrotik remote-displaying a console session.
I’m typically doing this over links that have <5Mb/s links, so filtering bandwidth even more wasn’t very desirable. I wasn’t saturating the link AFAICT. This seemed purely about CPU. I compressed the traffic trying to get a reproducer that didn’t need VNC, and ended up with stability.
My hunch is – something in Mikrotik’s ssh implementation reacted poorly to something in VNC’s compressed protocol. This might just be a timing thing. Once it consumes a lot of CPU, other things suffer, leading to a cascade failure.
It’d still be nice to be able to re-nice certain router subsystems. I certainly wouldn’t want, say, a web proxy to cause the rest of the Mikrotik to seize up.