BuyVM OpenVZ 128MB (NY)

• cat /proc/cpuinfo
  
  processor : 0
  vendor_id : GenuineIntel
  cpu family : 6
  model : 45
  model name : Intel(R) Xeon(R) CPU E5-2630L 0 @ 2.00GHz
  stepping : 7
  cpu MHz : 2000.354
  cache size : 4096 KB
  physical id : 0
  siblings : 8
  core id : 0
  cpu cores : 8
  apicid : 0
  fpu : yes
  fpu_exception : yes
  cpuid level : 13
  wp : yes
  flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc pni ssse3 cx16 sse4_1 sse4_2 popcnt lahf_lm
  bogomips : 4000.70
  clflush size : 64
  cache_alignment : 64
  address sizes : 40 bits physical, 48 bits virtual
  power management:
  
  
• cat /proc/meminfo
  
  Code:

  MemTotal:       262144 kB
  MemFree:        102004 kB
  Buffers:             0 kB
  Cached:              0 kB
  SwapCached:          0 kB
  Active:              0 kB
  Inactive:            0 kB
  HighTotal:           0 kB
  HighFree:            0 kB
  LowTotal:       262144 kB
  LowFree:        102004 kB
  SwapTotal:           0 kB
  SwapFree:            0 kB
  Dirty:             260 kB
  Writeback:           0 kB
  AnonPages:           0 kB
  Mapped:              0 kB
  Slab:                0 kB
  PageTables:          0 kB
  NFS_Unstable:        0 kB
  Bounce:              0 kB
  CommitLimit:         0 kB
  Committed_AS:        0 kB
  VmallocTotal:        0 kB
  VmallocUsed:         0 kB
  VmallocChunk:        0 kB
  HugePages_Total:     0
  HugePages_Free:      0
  HugePages_Rsvd:      0
  Hugepagesize:     2048 kB

• dd
  
  Code:

  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, 4.75213 s, 226 MB/s

• wget
  
  Code:

  wget cachefly.cachefly.net/100mb.test -O /dev/null
  
  --2013-05-19 20:28:03--  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 6.89M/s   in 17s
  
  2013-05-19 20:28:20 (5.71 MB/s) - `/dev/null' saved [104857600/104857600]

• Ruby scripts
• Thin cluster
• Rails app
• lighttpd + php

• One ticket for activating the free 5GB backup space.
• One ticket to reset my security question.

acd said:

This is the /proc/user_beancounters from my NY ovz128:

Spoiler

So explain what we should note from the beancounter info...

Click to expand...

buffalooed said:

@wlanboy, That traceroute to UK (guardian.co.uk) = retarded routing.

What is super disturbing about that route is we have the upstream handoffs going on.   XO --> COGENT --> Level 3 --> then Level 3 goes to Chicago and gets lost.

What is disturbing about that?  Colocrossing still supposedly has Level 3 in their upstream mix.  They should be able to stuff these packets in Level 3 straight out of Buffalo over to JFK over the pond and where are there.

They've monkeyed things so poorly that you have routing like what you've shown that is just nuts and makes you wonder if they actually have Level 3 there.

Not to be outdone, the other blend they serving up @Francisco and BuyVM out of Buffalo is even more broken perhaps:

3:  buf-b1-link.telia.net                                 0.830ms asymm  5 

 4:  216.156.0.253.ptr.us.xo.net                          14.455ms asymm  5 

 5:  te0-3-0-3.ccr22.ymq02.atlas.cogentco.com             14.977ms asymm  9 

 6:  4.68.127.245                                         13.295ms asymm  8 

 7:  te0-3-0-4.mpd21.lon13.atlas.cogentco.com             83.727ms asymm  9 

 8:  ae-71-71.ebr1.NewYork1.Level3.net                    89.755ms asymm 12 

 9:  ae-2-2.ebr2.NewYork2.Level3.net                     102.046ms asymm 12 

10:  ae-59-224.csw2.London1.Level3.net                    88.594ms asymm 11 

11:  4.69.201.45                                         102.025ms asymm 12 

12:  77.91.255.194                                        96.667ms asymm 13 

13:  77.91.255.141                                        91.159ms asymm 15 

14:  77.91.255.137                                        90.005ms 

15:  GUARDIAN-UN.car1.London1.Level3.net                  92.514ms asymm 10 

16:  77.91.255.141                                       103.272ms asymm 15 

17:  no reply

18:  77.91.255.194                                       105.729ms asymm 13 

 

Figure that mess out.  Looks like:

XO --> Cogent --> Cogent (London) --> Level 3 (NYC) --> Level 3 (London) --> 4.69.201.45 (which appears to be NYC Level 3 --- try a traceroute to that IP for fun) ---> Level 3 (London)

The latency doesn't add up though since we've basically gone from NY state to London then back to NY state then back to London.

Maybe @Francisco can comment on these messed up routes?

Click to expand...

Tux said:

You forgot that Telia was the first hop.

If you have the sick pleasure of using their services or an ISP that peers with them like me (this isn't to BuyVM, but still):


tux-amd64@tabuu:~$ traceroute mc.nullblock.com
traceroute to mc.nullblock.com (192.227.135.245), 30 hops max, 60 byte packets
<Internal stuff>
6 bbr02atlnga-bue-3.atln.ga.charter.com (96.34.2.72) 23.260 ms 17.677 ms 23.415 ms
7 bbr01atlnga-tge-0-0-0-2.atln.ga.charter.com (96.34.0.38) 24.284 ms 25.730 ms 25.713 ms
8 atl-bb1-link.telia.net (80.239.130.249) 51.881 ms 51.857 ms 51.838 ms
9 ash-bb3-link.telia.net (80.91.252.213) 49.362 ms ash-bb3-link.telia.net (213.155.134.130) 47.064 ms ash-bb3-link.telia.net (80.91.252.217) 51.727 ms
10 nyk-bb1-link.telia.net (213.155.130.78) 55.371 ms nyk-bb1-link.telia.net (213.155.134.126) 59.126 ms nyk-bb1-link.telia.net (213.155.131.226) 62.771 ms
11 buf-b1-link.telia.net (80.91.246.36) 64.149 ms 66.422 ms 64.377 ms
12 giglinx-ic-155660-buf-b1.c.telia.net (213.248.96.42) 66.158 ms 65.961 ms 67.538 ms
13 host.colocrossing.com (75.127.11.234) 88.140 ms 85.302 ms 84.969 ms
14 Node13.weloveservers.net (192.227.135.130) 68.479 ms 64.031 ms 62.395 ms
15 host.colocrossing.com (192.227.135.245) 66.384 ms 63.602 ms 59.914 ms
tux-amd64@tabuu:~$ ping -c 5 mc.nullblock.com
PING mc.nullblock.com (192.227.135.245) 56(84) bytes of data.
64 bytes from host.colocrossing.com (192.227.135.245): icmp_req=2 ttl=47 time=62.2 ms
64 bytes from host.colocrossing.com (192.227.135.245): icmp_req=3 ttl=47 time=61.8 ms
64 bytes from host.colocrossing.com (192.227.135.245): icmp_req=4 ttl=47 time=82.5 ms
64 bytes from host.colocrossing.com (192.227.135.245): icmp_req=5 ttl=47 time=66.9 ms

--- mc.nullblock.com ping statistics ---
5 packets transmitted, 4 received, 20% packet loss, time 4012ms
rtt min/avg/max/mdev = 61.855/68.390/82.562/8.420 ms
tux-amd64@tabuu:~$

That being said, I don't plan to ever use ColoCrossing in Buffalo, nor will I even really use them at all. I might go back if their routing was much better. This makes single-homed Cogent look like the best thing ever to me.

I'll end my Telia rant now (and hopefully my posts full of traceroutes ), but I certainly support BuyVM's decision to stop giving more hardware to ColoCrossing. I imagine that you should give Ashburn a try to be honest. I don't see too many LEB providers there other than Amazon (but it's "cloud", which to me is another word for "shit").

Click to expand...

buffalooed said:

Thanks for chiming in  I had to chuckle at some of it.  Cloud = SHIT.  Agreed.

Georgia to Buffalo, NY, in 65ms ... slow.

BuyVM holding back on hardware in Buffalo... Yeah, they've been.  Not a BuyVM kick in the sack, but plenty of other "providers" bit on Buffalo deals and they can't sell anything there.   Demand isn't great at that location.

Click to expand...

buffalooed said:

So explain what we should note from the beancounter info...

Click to expand...

acd said:

Basically, they don't underallocate you for anything in particular. A lot of hosts might cap your numprocs lower or limit your kmem size or your tcp socks/file handles to something you might actually hit. Buyvm doesn't; they set the params at a reasonable level and really only cap your ram, just as you would expect.


That's not why I attached it to the thread though. I try to find out what beancounters is set to before I pick up an ovz, but most times that is impossible.


You should take some time to learn how to read them; being able to read beancounters is good for you as a user, especially when things are failing for "no apparent reason". That failcount column will tell you if your hitting resource limits frequently.

Click to expand...