We are in the process of migrating this forum. A new space will be available soon. We are sorry for the inconvenience.

Classic VPS servers totally unsuable


SrvGuy
25-06-2015, 17:07
Ok, it seems that the problems are continuing. I'll file one more ticket, and if it happens again. I'll be off to RamNode? This is such a shame, because I'm completely hapy with the service except the freeze ups. I've configured local latency monitor which just monitors the availability of CPU by running a small loop every now and then and it clearly shows how the 2 ms loop can take over 2 minutes to run at times. And no, I'm not out of memory or low on resources. Something is wrong with the host. When I did read other forums, it seems that I'm not the only one suffering from this. So please, fix it, or if there's not interest of fixing it, I'll have to vote with my money.

SrvGuy
31-05-2015, 12:41
Rbx afaik, this is not network related. It's more like overload (memory swap trashing most likely) on the host running the processes.

Criot
29-05-2015, 11:10
What datcenter are you in? More than likely that you were affected by this, if you're in BHS: http://status.ovh.co.uk/?do=details&...478e98b95f1995

SrvGuy
29-05-2015, 06:18
This wasn't even bad, but gives a great indication what I'm talking about. Most interesting part here is that there was NO packet loss. Something is just bit slow at times.

64 bytes from vps: icmp_seq=3584 ttl=53 time=44.6 ms
64 bytes from vps: icmp_seq=3585 ttl=53 time=199 ms
64 bytes from vps: icmp_seq=3586 ttl=53 time=223 ms
64 bytes from vps: icmp_seq=3587 ttl=53 time=1364 ms
64 bytes from vps: icmp_seq=3588 ttl=53 time=359 ms
64 bytes from vps: icmp_seq=3589 ttl=53 time=12766 ms
64 bytes from vps: icmp_seq=3590 ttl=53 time=11921 ms
64 bytes from vps: icmp_seq=3592 ttl=53 time=10045 ms
64 bytes from vps: icmp_seq=3591 ttl=53 time=11053 ms
64 bytes from vps: icmp_seq=3593 ttl=53 time=9054 ms
64 bytes from vps: icmp_seq=3594 ttl=53 time=8046 ms
64 bytes from vps: icmp_seq=3595 ttl=53 time=7081 ms
64 bytes from vps: icmp_seq=3596 ttl=53 time=6073 ms
64 bytes from vps: icmp_seq=3597 ttl=53 time=5066 ms
64 bytes from vps: icmp_seq=3602 ttl=53 time=54.1 ms
64 bytes from vps: icmp_seq=3598 ttl=53 time=4079 ms
64 bytes from vps: icmp_seq=3599 ttl=53 time=3071 ms
64 bytes from vps: icmp_seq=3603 ttl=53 time=52.5 ms
64 bytes from vps: icmp_seq=3604 ttl=53 time=44.9 ms

Btw. When someone says OpenVZ is the problem, that's a lie. OpenVZ works just fine, I've been using it on my own servers as well as with other service providers and it's not the source of the problem. For baseline let's say that ~50ms is considered to be normal in this case.
Gotta launch at DO or Vultr.

SrvGuy
12-05-2015, 16:21
OVH Finland already dealt with it.


This is just for information so everyone reading this thread can make their own conclusions. OVH staff of course can see this information straightaway. I can also say that the "high" bandwidth consumption or "high" memory consumption are NOT correlated with the freeze ups. Usually CPU time on TOP is quite low, but the load indicator is showing something like 6+.

I'm not talking about 'production use', but I still would expect 'normal' and some what stable (in certain parameters) operation. I surely acknowledge it's budged server and I'm not expecting phenomenal (lol) CPU, IO, network performance. But the fact that the system completely freezes over for 2-3 minutes is something I really can't stand. And that's not only 1-2 times, it's repeated. Like I said, I once complained about it. After that it worked just as I would expect and I was very happy with it. Then those freezes came back. Now it's working again like a charm.

If you think about the freeze ups, that's not something you can tolerate even with personal website. Web sites should be reachable, even if slow, that's ok. But if it doesn't work at all. That's bad.

I completely agree with Marks comments from OVH. That's exactly what I'm asking for. I'm IT pro and we provide services to customers using several cloud hosting solution providers. UpCloud, OVH, Sigmatic, Hetzner and a few Telcos. I know you get what you pay for. Only think I'm dissatisfied with are the freeze ups. Which clearly seem to originate somewhere from the host platform. Based on my experience the vm host (If you can even say so when using OpenVZ / LXC) is running out of memory and swapping heavily, that's just what it feels like. Even ssh shell echo can at times just simply stop for 2 minutes.

Everything is now ok, and I hope the situation remains like this.

marks
12-05-2015, 12:16
yes, the Classic VPS is a budget VPS, not for business level applications or very heavy usage, but still, it should be stable if used within these premises.

It would be interesting to see the traffic graph of the VPS and the performance of the CPU/RAM (top output). could you give us some information?

If both are not huge, I would open an incident ticket with both logs for the engineers to check.

Thanks

Criot
11-05-2015, 19:21
It's not really surprising:
http://www.ovh.co.uk/vps/

If you hover over 'Classic VPS' you'll see it says test/development environment, basically they're not intended for Production. The VPS cloud is fantastic and I use it personally for my own website.

SrvGuy
11-05-2015, 19:16
There's something seriously wrong with the platform. It's performance varies from Okish to absolute night mare aka, no performance / availability at all. I'm running a few light sites on different VPS servers and I just can't take it anymore. I have a feeling that the host operating system is running out of memory and swapping hard. At least that's what it feels like. Even shell can freeze for several minutes so that nothing at all happens, even if there aren't ANY additional services or processes running than which came with the image.

It's horrible! Last time when I complained about it, they did something and it worked well for about a month, and now the situation is the same. I guess they moved my VPS to different host.

My friends have been complaining about the same issues. I guess I don't have other choice than relocate to another service provider.