OVH Community, your new community space.

EG BestOF 1Gbps - Download max 10MB/s (80Mbps) ovh proof


desavil
02-06-2012, 10:21
Tego nie miałem na myśli, tylko że po prostu usuną serwer tam - tak jak by wygasł i zamówią w RBX.

hdmagic
01-06-2012, 22:41
Nie no, bądźmy poważni. Nikt nie wymontuje twojego serwera i nie wyśle do starego DC.
Fizycznie musisz zamówić nowy serwer a za tamten dostaniesz na skarbonkę.

desavil
01-06-2012, 20:49
Po kontakcie telefonicznym z numerem "Zgłaszanie awarii" otrzymałem informację, że nawet jest chyba możliwość u handlowców zmiany datacenter serwera dedykowanego, bez ponownego kupowania itp. Hmm.

hdmagic
01-06-2012, 20:44
Tak, dokładnie. Pamiętaj jednak, że to ich dobra wola. Napisz ticket do handlowego i podeprzyj uprzejmościami

desavil
01-06-2012, 19:54
No to super... :/

Ja właśnie nie chciałem w Strasburgu, ale przy wyborze datacenter nie zauważyłem, że tam się wysuwa i zmienia ofertę. Myślałem na początku że to tylko serii MG się tyczy.
Możesz sprecyzować, jak oddałeś? Można go jakoś zamknąć i kwotę zyskać, np. do skarbonki?

hdmagic
01-06-2012, 19:50
Jeśli to Strasbourg to zerknij tu: http://forum.ovh.pl/showthread.php?t=15179

Oddałem serwer, zamówiłem w starym DC OVH i śmiga bez zająknięcia.
Znajomy kupił kilka dni temu w Strasburg i rozłącza co chwila ssh, nic zrobić się nie da, transfer wewnątrz OVH poniżej 40Mbits.

desavil
01-06-2012, 19:10
Witajcie!

Zakupiłem serwer dedykowany EG BestOF z łączem 1Gbps. Od razu po zainstalowaniu postanowiłem sprawdzić szybkość łącza i zonk...
Pobieranie pliku z proof OVH (http://proof.ovh.net/files/10Gb.dat) zarówno na serwerze uruchomionym z dysku jak i w trybie rescue, wyniki są podobne:
Kod:
--2012-06-01 15:20:55-- 
http://proof.ovh.net/files/10Gb.dat
Resolving proof.ovh.net... 188.165.12.106,
2001:41d0:2:876a::1
Connecting to proof.ovh.net|188.165.12.106|:80...
connected.
HTTP request sent, awaiting response... 200 OK
Length: 1250000000 (1.2G) [application/octet-stream] Saving to: `10Gb.dat'

100%[============================================================================================================================>] 1,250,000,000 6.09M/s   in 2m 17s

2012-06-01 17:23:13 (8.68 MB/s) - `10Gb.dat' saved [1250000000/1250000000]
Prędkość pobierania średnia to: 10MB/s (80Mbps), co jest stosunkowo mało dla serwera o łączu 1Gbps, więc coś tutaj chyba jest źle ustawione w OVH, ticket już poszedł, ale jak został zgłoszony o 18:08:58 tak do teraz status: Rozpatrzone (oczekuje na sprawdzenie przez technika).

Dodatkowo, aby wyeliminować problem z dyskiem twardym wykonałem jego testy w trybie rescue oraz sprawdziłem smart, żadnych błędów tam nie widzę,więc myślę, że dysk jest sprawny.

Dla porównania, na innym moim serwerze dedykowanym (również w OVH) z łączem 1Gbps, w tym samym czasie prędkość pobierania tego samego pliku wygląda następująco:
Kod:
--2012-06-01 17:21:22-- 
http://proof.ovh.net/files/10Gb.dat
Translacja proof.ovh.net... 188.165.12.106,
2001:41d0:2:876a::1
Łączenie się z proof.ovh.net|188.165.12.106|:80...
połączono.
Żądanie HTTP wysłano, oczekiwanie na odpowiedź... 200 OK
Długość: 1250000000 (1,2G) [application/octet-stream] Zapis do: `10Gb.dat'

100%[============================================================================================================================>] 1.250.000.000 92,9M/s   w  13s

2012-06-01 17:21:35 (92,8 MB/s) - zapisano `10Gb.dat' [1250000000/1250000000]
Czyli różnica jest zauważalna od razu.


Zastanawiają mnie wpisy w kern.log:
Kod:
egid:0/0, parent /bin/bash[sh:10563] uid/euid:0/0 gid/egid:0/0
Jun  1 20:02:01 nsXXX kernel: mdadm: sending ioctl 1261 to a partition!
Jun  1 20:02:01 nsXXX kernel: mdadm: sending ioctl 1261 to a partition!
Jun  1 20:02:01 nsXXX kernel: mdadm: sending ioctl 1261 to a partition!
Jun  1 20:02:01 nsXXX kernel: mdadm: sending ioctl 1261 to a partition!
Jun  1 20:03:01 nsXXX kernel: grsec: From 213.186.50.100: denied access of range 9a000 -> 9c000 in /dev/mem by /usr/sbin/dmidecode[dmidecode:10660] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[sh:10644] uid/euid:0/0 gid/egid:0/0
Jun  1 20:03:01 nsXXX kernel: mdadm: sending ioctl 1261 to a partition!
Jun  1 20:03:01 nsXXX kernel: mdadm: sending ioctl 1261 to a partition!
Jun  1 20:03:01 nsXXX kernel: mdadm: sending ioctl 1261 to a partition!
Jun  1 20:03:01 nsXXX kernel: mdadm: sending ioctl 1261 to a partition!
Jun  1 20:04:01 nsXXX kernel: grsec: From 213.186.50.100: denied access of range 9a000 -> 9c000 in /dev/mem by /usr/sbin/dmidecode[dmidecode:10745] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[sh:10729] uid/euid:0/0 gid/egid:0/0
Jun  1 20:04:01 nsXXX kernel: mdadm: sending ioctl 1261 to a partition!
Jun  1 20:04:01 nsXXX kernel: mdadm: sending ioctl 1261 to a partition!
Jun  1 20:04:01 nsXXX kernel: mdadm: sending ioctl 1261 to a partition!
Jun  1 20:04:01 nsXXX kernel: mdadm: sending ioctl 1261 to a partition!
Jun  1 20:05:01 nsXXX kernel: grsec: From 213.186.50.100: denied access of range 9a000 -> 9c000 in /dev/mem by /usr/sbin/dmidecode[dmidecode:10818] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[sh:10812] uid/euid:0/0 gid/egid:0/0
Jun  1 20:05:01 nsXXX kernel: mdadm: sending ioctl 1261 to a partition!
Jun  1 20:05:01 nsXXX kernel: mdadm: sending ioctl 1261 to a partition!
Jun  1 20:05:01 nsXXX kernel: mdadm: sending ioctl 1261 to a partition!
Jun  1 20:05:01 nsXXX kernel: mdadm: sending ioctl 1261 to a partition!
Może tutaj jest jakiś problem z płytą główną serwera, kablem SATA? Czy podać, ew. jeszcze logi z jakiegoś pliku aby takie coś potwierdzić, bo czekam na rozpatrzenie ale cicho, a niestety muszę go jak najszybciej wdrożyć do produkcji.

PS. Serwerownia - Strasburg

Pozdrawiam i liczę na pomoc.