# AnyNode OpenVZ 512MB



## wlanboy (Jul 17, 2013)

*Provider*: AnyNode
*Plan*: OpenVZ 512mb VPS
*Price*: 6$ per month - free for 3 month testing
*Location*: Chicago, IL

*Purchased*: 06/2013

*Hardware information:*


cat /proc/cpuinfo

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU L5520 @ 2.27GHz
stepping : 5
cpu MHz : 2266.746
cache size : 4096 KB
physical id : 0
siblings : 3
core id : 0
cpu cores : 3
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc arch_perfmon rep_good unfair_spinlock pni ssse3 cx16 sse4_1 sse4_2 x2apic popcnt hypervisor lahf_lm
bogomips : 4533.49
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:


cat /proc/meminfo

```
MemTotal:         524288 kB
MemFree:          324096 kB
Cached:           141888 kB
Active:            96720 kB
Inactive:          92268 kB
Active(anon):      18264 kB
Inactive(anon):    28836 kB
Active(file):      78456 kB
Inactive(file):    63432 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:        262144 kB
SwapFree:         262144 kB
Dirty:                 8 kB
Writeback:             0 kB
AnonPages:         47100 kB
Shmem:              2604 kB
Slab:              11192 kB
SReclaimable:       8208 kB
SUnreclaim:         2984 kB
```

dd

```
dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync && rm -rf test
16384+0 records in
16384+0 records out
1073741824 bytes (1.1 GB) copied, 14.6437 s, 73.3 MB/s
```

second dd

```
dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync && rm -rf test
16384+0 records in
16384+0 records out
1073741824 bytes (1.1 GB) copied, 15.4999 s, 69.3 MB/s
```

wget

```
wget cachefly.cachefly.net/100mb.test -O /dev/null
--2013-07-17 11:29:35--  http://cachefly.cachefly.net/100mb.test
Resolving cachefly.cachefly.net (cachefly.cachefly.net)... 205.234.175.175
Connecting to cachefly.cachefly.net (cachefly.cachefly.net)|205.234.175.175|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: `/dev/null'

100%[========================================================================================================================================================>] 104,857,600 11.2M/s   in 9.0s

2013-07-17 11:29:44 (11.1 MB/s) - `/dev/null' saved [104857600/104857600]
```

*What services are running?*


MongoDB
Node.js dev area

*Support:*

First note: This is a beta test of their service. 3 free months in exchange for a lot of testing and suggestions.

The first month was rough. They had to fix the Fedora and Ubuntu templates. The network was not as good as today. There was a problem with vswap too. And their own developed vps panel did need some workflow enhancements.

But the second month was without any issues. The support guys are friendly but need their time to respond to the ticket.

I think that was caused by the huge amount of testing.

Looking to the first month I remember about creating at least one ticket a day. Reinstalling my vps to test each template and reinstall my Node.js environment again and again to see if everything is working as it should.

Currently I am using the Debian7 template. A well made mininstall template I really like.
 

*Overall experience:*

I do have another vps in Chicago and as far as I can tell the network is as good as on the other provider. So he.net is not as bad as it's reputation as an uplink provider (for EU clients). CPU is ok but the dd is lacking sometimes. But that is just a number, the system is fast. The MongoDB is running well.

I will create a ticket today to see if some abuser is killing the disks. And I will update the review with a second dd test afterwards.

Final words: I would recommend them if someone is searching for a friendly provider in Chicago.

traceroute to lemonde.fr:


2 74.119.218.185.rdns.continuumdatacenters.com (74.119.218.185) 0.633 ms 0.519 ms 0.985 ms
3 gige-g11-16.core1.chi1.he.net (184.105.253.1) 3.977 ms 3.939 ms 3.639 ms
4 10gigabitethernet3-2.core1.atl1.he.net (184.105.223.226) 21.447 ms 21.449 ms 21.462 ms
5 10gigabitethernet4-1.core1.mia1.he.net (72.52.92.54) 37.695 ms 37.679 ms 37.571 ms
6 miami-6k-1.proxad.net (198.32.124.192) 176.709 ms 175.172 ms 173.878 ms
7 washington-6k-1-po4.intf.routers.proxad.net (212.27.56.185) 129.501 ms 130.630 ms *
8 th2-6k-3-po10.intf.routers.proxad.net (212.27.57.13) 129.606 ms 129.679 ms 131.816 ms
9 th2-crs16-1-be1006.intf.routers.proxad.net (212.27.59.205) 130.977 ms 129.926 ms 130.297 ms
10 dedibox-1-p.intf.routers.proxad.net (212.27.58.46) 172.053 ms 172.216 ms 172.116 ms
11 a9k1-1013.dc3.online.net (88.191.1.132) 130.964 ms 130.893 ms 133.018 ms
12 6k1-1046.dc2.online.net (88.191.1.254) 171.867 ms 172.151 ms 171.881 ms

traceroute to dvhn.nl:


2 74.119.218.185.rdns.continuumdatacenters.com (74.119.218.185) 222.644 ms 222.627 ms 222.521 ms
3 gige-g11-16.core1.chi1.he.net (184.105.253.1) 1.719 ms 1.853 ms 1.797 ms
4 100gigabitethernet7-2.core1.nyc4.he.net (184.105.223.162) 18.825 ms 19.029 ms 18.971 ms
5 10gigabitethernet6-4.core1.lon1.he.net (72.52.92.242) 97.228 ms 97.152 ms 87.345 ms
6 linx-2601.ge-0-1-0.jun1.thn.network.bit.nl (195.66.225.51) 87.560 ms 87.781 ms 87.713 ms
7 806.xe-0-0-0.jun1.bit-2a.network.bit.nl (213.136.1.109) 102.292 ms 102.213 ms 102.551 ms

traceroute to sueddeutsche.de:


2 74.119.218.185.rdns.continuumdatacenters.com (74.119.218.185) 0.620 ms 0.806 ms 0.725 ms
3 gige-g11-16.core1.chi1.he.net (184.105.253.1) 1.437 ms 1.376 ms 1.284 ms
4 100gigabitethernet7-2.core1.nyc4.he.net (184.105.223.162) 18.466 ms 18.414 ms 18.356 ms
5 10gigabitethernet6-4.core1.lon1.he.net (72.52.92.242) 87.297 ms 87.245 ms 87.323 ms
6 ldngw1.arcor-ip.net (195.66.224.209) 89.882 ms 87.437 ms lndgw2.arcor-ip.net (195.66.224.124) 134.071 ms
7 85.205.25.117 (85.205.25.117) 91.863 ms 85.205.25.113 (85.205.25.113) 91.356 ms 91.416 ms
8 92.79.213.165 (92.79.213.165) 107.949 ms 107.895 ms 107.451 ms
9 92.79.201.226 (92.79.201.226) 155.073 ms 155.196 ms 155.132 ms
10 92.79.203.158 (92.79.203.158) 143.793 ms 143.982 ms 144.786 ms
11 188.111.149.118 (188.111.149.118) 146.464 ms 136.345 ms 143.979 ms
12 195.50.167.227 (195.50.167.227) 145.258 ms 144.939 ms 145.141 ms

traceroute to washingtonpost.com:


```
2  74.119.218.185.rdns.continuumdatacenters.com (74.119.218.185)  0.591 ms  0.700 ms  0.684 ms
 3  gige-g11-16.core1.chi1.he.net (184.105.253.1)  2.681 ms  2.408 ms  2.065 ms
 4  mpr1.ord7.us (206.223.119.86)  5.610 ms  5.748 ms  6.148 ms
 5  xe-2-3-0.cr1.ord2.us.above.net (64.125.22.209)  5.932 ms  6.179 ms  6.000 ms
 6  xe-2-1-0.cr1.lga5.us.above.net (64.125.27.170)  29.777 ms  29.059 ms  29.199 ms
 7  xe-3-2-0.cr1.dca2.us.above.net (64.125.26.101)  28.084 ms  28.052 ms  29.497 ms
 8  xe-1-1-0.mpr3.iad1.us.above.net (64.125.31.113)  28.421 ms  27.027 ms  27.072 ms
 9  64.124.201.150.allocated.above.net (64.124.201.150)  27.891 ms  27.776 ms  27.502 ms
10  208.185.109.100 (208.185.109.100)  27.799 ms  27.189 ms  28.016 ms
```


----------



## anyNode (Jul 17, 2013)

We appreciate the review wlanboy!


----------



## wlanboy (Jul 17, 2013)

anyNode said:


> We appreciate the review wlanboy!


No problem. I enjoyed the beta testing.


----------



## wlanboy (Jul 18, 2013)

I run a second dd. Quite the same results.

Got a answer on my ticket too:


```
The low dd speeds are likely due to the fact we're running 4 disk RAID10s per node. 
I'm seeing around 100 MB/s on the node side which is acceptable but still low. 
Our next batch of nodes will be running 8 disk RAID10s with a more powerful controller 
so we should be seeing significant I/O improvement then.
```


----------



## Jack (Jul 19, 2013)

wlanboy said:


> I run a second dd. Quite the same results.
> 
> Got a answer on my ticket too:
> 
> ...



I run 4 disks in RAID10 with/out HW Controllers and they run at 150-200MB/s

What disks are you using to get <100MB/s?


----------



## scv (Jul 19, 2013)

We're using 4x WD Red 3TB in each node. I just ran another set of dd tests and results are more like what I'd expect but still lacking.


[[email protected] ~]$ dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync; rm test
16384+0 records in
16384+0 records out
1073741824 bytes (1.1 GB) copied, 6.46158 s, 166 MB/s
[[email protected] ~]$ dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync; rm test
16384+0 records in
16384+0 records out
1073741824 bytes (1.1 GB) copied, 6.11453 s, 176 MB/s
[[email protected] ~]$ dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync; rm test
16384+0 records in
16384+0 records out
1073741824 bytes (1.1 GB) copied, 6.83297 s, 157 MB/s


As was stated in the ticket wlanboy posted, our next batch of nodes are going to be running a more powerful controller with 8 disks. In addition to that we have a few tweaks we'd like to make to our nodes but it'll require a reboot, so we're holding off on that until our next scheduled maintenance window.


----------



## SeriesN (Jul 19, 2013)

Jack,


You need to understand that this is a beta node. Probably every one is benchmarking and abusing the shit out of it.



Jack said:


> I run 4 disks in RAID10 with/out HW Controllers and they run at 150-200MB/s
> 
> 
> What disks are you using to get <100MB/s?


----------



## Jack (Jul 22, 2013)

SeriesN said:


> Jack,
> 
> 
> You need to understand that this is a beta node. Probably every one is benchmarking and abusing the shit out of it.


Ah! I didn't see that bit.


----------



## MartinD (Jul 22, 2013)

Ahh, good old 'dd' making an appearance. The 'benchmark' for everyone.

If only people actually knew what they were doing it would be a touch more palatable.

Say after me everyone....

*'dd' IS NOT INDICATIVE OF REAL WORLD PERFORMANCE.*


----------



## notFound (Jul 22, 2013)

MartinD said:


> Ahh, good old 'dd' making an appearance. The 'benchmark' for everyone.
> 
> If only people actually knew what they were doing it would be a touch more palatable.
> 
> ...


Hehe, I prefer ioping which is much more indicative of 'real life disk performance'.


----------



## wlanboy (Jul 23, 2013)

Did anyone read that?



> CPU is ok but the dd is lacking sometimes. But that is just a number, the system is fast. The MongoDB is running well.


----------

