New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
What tests can I run when SSH'ng into a VPS starts to sssssllllowwwww down?
Every once in a while my terminal session with a VPS becomes unresponsive or just slows down (ie typing a character may take a few seconds before it actually displays).
Of course, sometimes, it is due to some app (like FTP) that I am running locally in the background, but often not.
So I was wondering, when this happens, are there any standard tests (besides ping) that you can run on your VPS to track down the culprit and help you determine whether the bottleneck is on the VPS provider's side or just some net related 'hiccup'? What do you do?
Follow-up note: Sometimes just logging out, then back in, takes care of the problem.
Comments
Install MTR on another server and watch the effected server. My guess is that the route to your VPS has packet loss occurring somewhere causing your SSH session to act buggy.
Mun
Thanks for the idea. So I installed MTR on a server and ran a '--report' to the other server, resulting in:
I'm not sure why the 100% loss on the first hop. The firewall didn't stop any packets on the origin server, and there is no firewall up on the destination.
top/htop might help.
Did you do the MTR while you were having issues?
Mun
The short version: First hop/any hop that has 100% loss is a firewall dropping icmp packets so long as the hops after it do not have 100% loss. Only worry about a hop that has high % loss with high % loss after that hop.
You can also try using larger packet sizes to stress the network and demonstrate issues.
Install mosh. I rarely SSH if it's outside of my network now
I tried mosh a while back but kept getting errors and could never get it working. Maybe its time to give it another try.
dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync; unlink test
Run the above and tell us the output, it might be a really slow disk I/O
Maybe your local internet speed is slow?
Nope, because I have no problems ssh'n into various other VPSes. It doesn't happen on just one VPS provider, pretty much all of them every once in a while, so I was just wondering what I could do to determine the cause..when it happens.
Right now everything is fine, but when it happens again I will try Mun's suggestion and report back.
Thanks
@gutshotz do exactly this. When a lot of process are hogging the CPU+i/o, it leads what you are facing (OpenVZ).
Ok, so it slowed down again just now and I ran those tests:
What does it mean? Running the same test on another, very responsive VPS, gave:
Quite the difference, so I take it 44.8MB/S means something on the VPS is hogging resources?
I just tried it again on the slow VPS and it is now 90.3MB/s, but still nowhere near the 1.0GB/s of my RamNode VPS.
Now wait for the server to be working fine and rerun the test, but 40 MBps is fine. Ramnode has very good I/O and isn't a good measure against your current VPS that is having issues.
It is responsive again, so I ran the test and got 90.8/MBs - pretty much the same as my last test. So that didn't really reveal the source of the slowdown...I'm going to try running mosh again, to see if that makes any difference.
My guess is still that you are having packet loss, try and do an MTR when you notice the slow down.
Mun
Alright a couple of my sessions turned into molasses today, each on a different provider in different regions (NY and LV), and both had dd test results around the 40/MBs mark.
When I ran 'mtr --report my.host.com' or 'mtr --report IP' the packets get lost after passing my local router (192.168.2.1). I even disabled the firewall on the VPSes, and made sure no local firewall wasn't stopping any packets. What is going on?
And a ping results in:
And mtr from one VPS to another:
Add 'UseDNS no' to ssh config and /etc/init.d/ssh restart.
It might help.
already a standard setting in all my VPSes