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.
An Example of Professionalism from Crissic
I tried to do a wget with a Cachefly file yesterday and only got speeds of 1MB/s
I sent in a ticket with Crissic and they informed me that the issue was not on their end. I get the feeling the problem is on Crissic's end but they claim they ran the same wget on a different VPS and did not receive unusual speeds.
I'm a little confused what's causing the issue as I would normally expect it to be 40MB/s+
The only network config (gai.conf) change I've made is for IPv4 to take precedence in favour of IPv6 whenever possible, in regards to that apt-get bug. There is no firewall and I/O is just fine at 77MB/s.
How would I troubleshoot this issue?
Thanked by 1Boxode
Comments
Results inside a container on your very node:
wget -O /dev/null http://cachefly.cachefly.net/100mb.test
--2014-05-04 05:07:04-- http://cachefly.cachefly.net/100mb.test
Resolving cachefly.cachefly.net... 205.234.175.175
Connecting to 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 73.8M/s in 1.4s
2014-05-04 05:07:06 (73.8 MB/s) - `/dev/null' saved [104857600/104857600]
Firstly, I would try downloading from something other than Cachefly, perhaps if the datacenter has a test IP or if Crissic has a test IP, this should give you an indication on if there's a network bottleneck or other issue somewhere. Then you can move to bandwidth that is outside the DC and test with other files.
There are so many reasons that it could be this way.
Try to test the speed with another service (speedtest.net for example) or with another box you maybe have.
Then, traceroute your vps with cachefly to see if there is any issue.
If you want to test with a random server of speedtest.net, try this script:
And this is my test on a crissic box with cachefly. Pretty good!
Results inside a container on your very node:
I'm not doubting you, I'm sure there's some kind of misconfiguration with my VPS.
Somehow my VPS rebooted and the speeds have improved to 2MB/s
I'm gonna also look at a few other VPS in the same /24 subnet as your container just in case. I don't believe this to be the issue but you never know.
I'll update your ticket if I see anything.
Surely the first thing you would do is download from elsewhere, just to make sure the issue isn't cachefly? Basic troubleshooting logic there bro.
I'm gonna also look at a few other VPS in the same /24 subnet as your container just in case. I don't believe this to be the issue but you never know.
Thank you very much. I'm going to see if there is indeed some kind of misconfiguration error but I'm not too well versed on networking.
Try to test the speed with another service (speedtest.net for example) or with another box you maybe have. Then, traceroute your vps with cachefly to see if there is any issue.
@Nekki
wget -O /dev/null http://speedtest.dal05.softlayer.com/downloads/test100.zip--2014-05-03 17:16:36-- http://speedtest.dal05.softlayer.com/downloads/test100.zip
Resolving speedtest.dal05.softlayer.com (speedtest.dal05.softlayer.com)... 173.192.68.18
Connecting to speedtest.dal05.softlayer.com (speedtest.dal05.softlayer.com)|173.192.68.18|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104874307 (100M) [application/zip]
Saving to: `/dev/null'
0% [ ] 1,155 --.-K/s eta 57d 22h
KVM or OpenVZ?
If KVM, you can try applying the optimizations in this thread:
http://lowendtalk.com/discussion/25317/fixing-network-speed-in-kvm
Although, I've never noticed speeds that low previous to those optimizations.
KVM or OpenVZ?
OpenVZ, sadly those don't apply to me and I can't modify the kernel.
@darknyan When you save the script, the, you have to run it.
Try
./speedtest-cli --sharewithin your speedtest created directory
This is the result from my skylar's server
Should always run tests in the Atlanta area or somewhere thereabouts. Everything but Atrato backhauls to Atlanta, so it's going to route up to atlanta, then back down to Florida if using a Florida test server.
Seeing some questionable results for the 162.220.8.0/21 block, investigating now. Does appear to replicate similar speed results as the OP with containers in the same IP range, on the same node and on different ones.
Try grabbing a file from that VPS and see whether you get the same shitty performance or not.
@SkylarM Well, I'm from Greece, so, I usually test from a greek server of speedtest.net.
E.g.
That is pretty good for 9177.86 km distance with a biiiiig traceroute!
I would be more concerned about the upload, i've seen providers who say the network is fine just because a test file downloads great, but upload is like 1mbit...
Here's mine:
I like the FreeVPS benchmark script to easily test a few locations from a one-liner.
My VPS is in the 162.218.208.0/22 CIDR
More specifically the 162.218.211 range.
Download speed from CacheFly: 1.05MB/s
Download speed from Coloat, Atlanta GA: 1.15MB/s
Download speed from Softlayer, Dallas, TX: 1.10MB/s
Download speed from Linode, Tokyo, JP: 8.31MB/s
Download speed from i3d.net, Rotterdam, NL: 4.71MB/s
Download speed from Leaseweb, Haarlem, NL: 18.5MB/s
The speeds to Japan and The Netherlands are higher than to the US itself?
Definately not right. We're troubleshooting now, but it seems to be sort of hit or miss on if a container is performing fine. The network itself is great, as is nodes themselves. A few IPs in the 162.220.12.0 block are giving low results, but it's not anything that really makes much sense from a network standpoint.
If you can do me a favor and open a ticket so I have a more accurate IP to look at I'd appreciate it. Also if you can include what operating system is installed that may also help pinpoint a potential issue with an older template (if there is any similarities).
What do you run at your vps darknyan? Do you run torrent or maybe proxy? It may slow down the vps. And also try to check the /etc/resolv.conf
Here we go. https://www.petabyet.com/result/2014-05-03-681cc37944316bda2666355a0f5d2cbf/
If you are seeing network slowdowns, please open a ticket with support so we can gather more information to try and troubleshoot. Network as a whole is fine, seems to be isolated to a few clients so want to figure out if there are any similarities between containers.
Can you PM me or open a ticket with your service IP? So far seems to be all impacted containers are a variant of Debian that installed a few months ago, so I'm thinking it may be an issue with an older openvz template. New, fresh installs in the same IP blocks as those impacted on the same nodes are performing normal.
Additional information such as when you ran an update for software may prove useful.
I assume speeds like this aren't correct?
@SkylarM
PM'd.
it's not. Drop a ticket or PM me with IP so I can add it to our list of looking into.
Brief update, we are still troubleshooting.
There's a small handful of VPS impacted by this, all in different subnets and on different host nodes.
Some containers a simple reboot seems to fix it, while others a migration to our second cab seems to fix the issue. Again this is an isolated incident with very little in common between servers experiencing issues, and will provide an update as soon as we know more.
Thanks for the reports! If anyone else notices issues, please feel free to drop me a PM with your IP as well, just so we have more data
Remember if everyone is running the tests at the same time your bound to slow their network
Each server is on a 1gbit uplink to a 10gbit switch, to a router which has 20gbit of total connectivity (1x10gbit to NodesDirect, 1x10gbit to a direct Atrato commit). I really doubt you'd see multiple users running tests causing everything to go to 2M/s consistently
. You may see some variance in speed test results, but not that far.