I'm a very happy Linode.com (an US VPS supplier) customer and my expectations regarding service quality are pretty high. VPS is a virtualization technique that allows to share the same hardware among few operating systems with dedicated IP and root access. Having migration to another server in mind I've decided to give a try our European VPS providers.
One of the biggest hosting providers is OVH. I hope those French guys do better hosting services than cars 🙂
Minimum VPS offer is reachable for 5 EUR + VAT / month. It gives you only 512MB of RAM:
Despite the fact that they announce only 64-bit systems I was very surprised to see 32-bits of operating system version as well (at least of my favourite Debian) available:
The biggest benefit of 64-bit systems are (if you have less than 3GB of RAM) is that you get slight performance upgrade, but you have to pay in slightly bigger memory usage. As CPU resources are usually less important for me than available RAM (especially on low-end VPS instance) I've decided to go with 32-bit version then.
We have three locations in Europe available for selection, I went with Strasbourg as it's close to German border (so to Warsaw/Poland):
You can pay monthly, quarterly, twice a year or yearly. I've selected 3 months (to have a chance to evaluate server stability and performance over a longer period).
Manager software at OVH is the ugliest web interface I've ever seen. It opens new window on every possible occasion, is totally littered and it's very hard to find out there anything.
Anyway, I've switched to "new" interface (another one?) to manage new VPS system. Here you have few typical options you can expect from a VPS provider interface:
- transfer used
- selected ports status (nice feature, I can say)
- admin options: reboot, password reset, reinstall, reverse DNS, OS reload, console prompt, offer change
Note that there's only one (primary) IP address available, so you will have some trouble when hosting multiple HTTPS sites.
Let's check what's inside then.
Ping time from Warsaw is not bad, we have 37ms average time for a packet (ICMP) travel:
$ ping -c 5 18.104.22.168 PING 22.214.171.124 (126.96.36.199) 56(84) bytes of data. 64 bytes from 188.8.131.52: icmp_req=1 ttl=54 time=38.3 ms 64 bytes from 184.108.40.206: icmp_req=2 ttl=54 time=38.8 ms 64 bytes from 220.127.116.11: icmp_req=3 ttl=54 time=41.6 ms 64 bytes from 18.104.22.168: icmp_req=4 ttl=54 time=35.2 ms 64 bytes from 22.214.171.124: icmp_req=5 ttl=54 time=35.3 ms --- 126.96.36.199 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4006ms rtt min/avg/max/mdev = 35.282/37.899/41.625/2.371 ms
We can inspect whole route with more details:
$ mtr --report 188.8.131.52 HOST: dt Loss% Snt Last Avg Best Wrst StDev (...) 8.|-- fra-5-6k.fr.eu 40.0% 10 37.4 37.4 29.1 55.2 9.4 9.|-- sbg-g2-a9.fr.eu 0.0% 10 48.7 46.4 33.7 83.7 15.0 10.|-- sbg-s9-6k.fr.eu 90.0% 10 36.5 36.5 36.5 36.5 0.0 11.|-- 50.ip-37-187-39.eu 0.0% 10 36.9 42.2 35.0 62.1 8.4 12.|-- 178.ip-37-187-198.eu 0.0% 10 40.8 38.0 32.0 48.6 5.1
Finally: the speed tests performed using HTTP (no encryption overhead on VPS, median result from three runs):
# wget -O /dev/null http://184.108.40.206/a.zip --2014-02-06 23:15:44-- http://220.127.116.11/a.zip Connecting to 18.104.22.168:80... connected. HTTP request sent, awaiting response... 200 OK Length: 4415803 (4.2M) [application/zip] Saving to: `/dev/null' 100%[================================>] 4,415,803 8.04M/s in 0.5s 2014-02-06 23:15:45 (8.04 MB/s) - `/dev/null' saved [4415803/4415803]
OVH promises 100 MBit/s, thus ~10 MB/s. As we can see real values are slightly lower, near 8 MB/s. It's not bad (I used U.S. server to test, so may hit local bandwidth restrictions).
# free -h total used free shared buffers cached Mem: 512M 16M 495M 0B 0B 9.0M -/+ buffers/cache: 7.7M 504M Swap: 128M 0B 128M
It's o,5GB as specified in offer. Note that for OpenVZ your kernel memory is not counted towards used memory – it's different memory model than XEN where you have separate kernel.
For OpenVZ virtualization you might have some additional restrictions (besides memory for all your processes). You can reach those values by /proc/user_beancounters file:
# cat /proc/user_beancounters Version: 2.5 uid resource held maxheld barrier limit failcnt 46990: kmemsize 10343161 13320192 9223372036854775807 9223372036854775807 0 lockedpages 0 489 131072 131072 0 privvmpages 1925 25304 131072 524288 0 shmpages 647 663 9223372036854775807 9223372036854775807 0 dummy 0 0 9223372036854775807 9223372036854775807 0 numproc 15 33 9223372036854775807 9223372036854775807 0 physpages 41390 47954 0 131072 0 vmguarpages 0 0 131072 131072 0 oomguarpages 833 833 131072 131072 0 numtcpsock 5 5 9223372036854775807 9223372036854775807 0 numflock 1 7 9223372036854775807 9223372036854775807 0 numpty 1 4 9223372036854775807 9223372036854775807 0 numsiginfo 0 12 9223372036854775807 9223372036854775807 0 tcpsndbuf 87200 111312 9223372036854775807 9223372036854775807 0 tcprcvbuf 81920 862096 9223372036854775807 9223372036854775807 0 othersockbuf 0 19736 9223372036854775807 9223372036854775807 0 dgramrcvbuf 0 8720 9223372036854775807 9223372036854775807 0 numothersock 18 22 500 500 0 dcachesize 5574544 7664915 9223372036854775807 9223372036854775807 0 numfile 190 280 9223372036854775807 9223372036854775807 0 dummy 0 0 9223372036854775807 9223372036854775807 0 dummy 0 0 9223372036854775807 9223372036854775807 0 dummy 0 0 9223372036854775807 9223372036854775807 0 numiptent 24 24 9223372036854775807 9223372036854775807 0
Typically kmemsize (kernel size for this guest OS) and numproc (the number of available processes) is restricted (I've learned 1&1 restricts numproc to 160!). Here we have no restrictions added for those two parameters, good.
As specified we can see only one core, so will be limited here:
# grep 'cpu MHz\|bogomips' /proc/cpuinfo cpu MHz : 3000.000 bogomips : 6000.00
The bogomips value (+/- perfomance of the CPU) is 50% better than my 2GHz laptop. The difference comes from higher CPU clock used (3GHz vs 2 GHz).
Typical resource that is oversold by hosting companies. I'm not talking about space itself, but about performance. I've seen many comlaints in the past related to high IO lags (thus high load) due to overused disk usage on crowded servers for virtual and classic hosting.
We can see simfs (virtual filesystem), inodes are shared with host:
# df -h Filesystem Size Used Avail Use% Mounted on /dev/simfs 25G 401M 25G 2% / tmpfs 52M 28K 52M 1% /run tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 128M 0 128M 0% /run/shm
As we are on OpenVZ container we don't have access to hdparm tool. We can make quick & dirty workaround for measure disk write speed (medium result selected):
# sync; dd if=/dev/zero of=/tmp/test bs=64k count=16k; rm /tmp/test 16384+0 records in 16384+0 records out 1073741824 bytes (1.1 GB) copied, 8.67465 s, 124 MB/s
Not bad, probably disk is not overloaded. For comparison my ThnkPad with 5200 RPM HDD:
$ sync; dd if=/dev/zero of=/tmp/test bs=64k count=16k; rm /tmp/test 16384+0 records in 16384+0 records out 1073741824 bytes (1,1 GB) copied, 33,3557 s, 32,2 MB/s
Geez, I should switch to SSD! 🙂
As you probably know that above measurements are worth nothing if you have long downtimes and / or periods with extremely high load of a host I've launched monitoring of HTTP response time to track changes over longer period:
I'll shave stats report as soon as they're ready in separate post. I can share my recommendation then: is OVH VPS worth of your money or not.
UPDATE 2015-03-17: In recent day OVH started to randomly kill my processes (OOM on host?) even if I'm much below OpenVZ limits and allocated memory usage. I switched to another provider instantly. Thus I DO NOT RECOMMEND OVH VPS SOLUTION. Select Linode instead, you will save your time and money.