OVH Community, votre nouvel espace communautaire.

Gros problème de bande passante


phil
10/03/2014, 14h29
Un peu beaucoup abusé de leur part ... :'(

Technogeek
10/03/2014, 05h14
Bah j'leur avait fait un ticket hein, mais ils m'ont dit de faire des test en rescue sur 2 machines en même temps, désolé mais j'ai pas que ça à foutre de prendre du downtime sur 2 machines en même temps.

phil
05/03/2014, 10h42
Ben dès fois tu peux avoir de légère différences d'une install à l'autre. Mais à mon sens, avec les tests que tu avais fait, tu pouvais tout à fait légitimement remonter un ticket incident auprès du support OVH. Cela m’ennuie quand même que tu ais eu à te battre avec eux. On paye justement SYS plus cher que kimsufi pour avoir un vrai support.


Phil

Technogeek
04/03/2014, 17h59
Peux être que c'est moi le con dans l'histoire, mais sur le cas présent comme dit j'ai balancer exactement la même chose sur la machine d'un autre hébergeur et je n'ai AUCUN soucis, qu'on vienne pas me dire que le problème viens de moi.

phil
03/03/2014, 20h54
Arf! je pensais qu'on était censé avoir du support sur les SYS :-(

Technogeek
03/03/2014, 11h45
Honnetement ? J'ai pas eu le temps de le faire.
De toute façon c'est claire que je suis limité à "75M", pas envie de passer en rescue ni rien, pour l'instant je passe le traffic sur une machine d'un autre hébérgeur qui elle à une vraie connexion apparament, marre de me battre avec le support SYS à la con.

phil
02/03/2014, 10h31
Justement, ethtool te dit si tu es en full duplex ou half. :-)
Sinon qu'ont donné tes tests?

Technogeek
02/03/2014, 00h47
Comment puis-je voir si je suis bien en fullduplex ?

eth0 Link encap:Ethernet HWaddr 08:60:6e:e5:bf:f0
inet addr: Bcast: Mask:255.255.255.0
inet6 addr: Scope:Link
inet6 addr: Scope:Global
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1942202209 errors:0 dropped:139 overruns:0 frame:0
TX packets:2648049162 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:249103552766 (249.1 GB) TX bytes:303000430001 (303.0 GB)

Sinon le ethool eth0 m'affiche bien 1000

phil
01/03/2014, 23h14
(avec dd bs=1M count=10 if=/dev/zero | nc IP 2000)

10485760 octets (10 MB) copiés, 14,6854 s, 714 kB/s
Oui, 714 kB, ça fait du ~7Mbps... C'est très moche.

Fais juste attention à une chose, ton test avec le wget
2014-03-01 20:10:40 (20,2 MB/s) - `/dev/null' saved [10737418240/10737418240]
Il s'agit de 20MO/s, soit en tenant compte de 1 octet = 8 bits + entête tcp/ip et ethernet doit donner de 200Mbps. Ajoute à cela tes 50Mbps de trafic, ton interface monte à peine à 250 Mbps.

Penses, avant de passer au mode rescue, à faire
  • ifconfig eth0
  • ethtool eth0

Afin de voir si l'interface ne perd pas de paquets et aussi si elle est bien en full duplex. C'est idiot, mais dès fois ça arrive qu'elle monte en half.

Philippe

Technogeek
01/03/2014, 19h12
Bonjour,

Donc avant de faire mes tests en rescue, je l'ai est fait en période "pleine" avec le serveur en prod.

Un DL d'un fichier du serveur web la nuit depuis ma connexion fonctionne rapidement à hauteur maximal de ma connexion.
En journée vers 19h avec pas mal de monde : Je DL un fichier de mon serveur à 90 ko/s. Depuis le VPS d'un ami même résultat, depuis une machine d'un concurrent même résultat.

Pourtant mes statistiques stagnent à 75M (en up), http://prntscr.com/2wy1t6 pas moyens d'aller au dessus, donc techniquement rien ne devrais bloquer à ce point là le UP. vue que je ne suis pas à la limite des 200M.

Bien sur le résultat est exactement le même depuis mes 3 autres machines SYS qui elles n'ont aucun problème entre elle (en même temps elle n'utilisent que "10M")

Exemple d'un wget (d'un VPS d'un ami)

[root@server1 ~]# wget http://test-debit.free.fr/65536.rnd
2014-03-01 18:23:50 (3.00 MB/s) - `65536.rnd' saved [67108864/67108864]
[root@server1 ~]# wget http://URLDEMONSERV/Unfichier
2014-03-01 18:21:28 (60.6 KB/s) - `Unfichier' saved [5182549/5182549]

(1er wget chez Free, 2nd sur mon serveur.)

J'ai les mêmes résultats chez moi.

Sur la machine posant problème j'ai aussi fait des tests de lecture écriture sur le SSD:
Ecriture : 1073741824 bytes (1,1 GB) copied, 9,10618 s, 118 MB/s
Lecture : 1073741824 bytes (1,1 GB) copied, 0,140527 s, 7,6 GB/s

(Notez que ceci sont les résultats en prod en heure de pointe. d'ou l'écriture peux être plus lente)

Un WGET de : http://proof.ovh.net/files/10Gio.dat -O /dev/null

root@ns313997:~# wget http://proof.ovh.net/files/10Gio.dat -O /dev/null
--2014-03-01 20:02:13-- http://proof.ovh.net/files/10Gio.dat
Resolving proof.ovh.net (proof.ovh.net)... 2001:41d0:2:876a::1, 188.165.12.106
Connecting to proof.ovh.net (proof.ovh.net)|2001:41d0:2:876a::1|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 10737418240 (10G) [application/octet-stream]
Saving to: `/dev/null'

100%[===================================>] 10 737 418 240 21,2M/s in 8m 27s

2014-03-01 20:10:40 (20,2 MB/s) - `/dev/null' saved [10737418240/10737418240]

Ce qui me parait assez lent. (Sachant que la co utilisé en Upload était de 75M à ce moment là environ et en DL à 50M d'après les stats SYS)


Sur mes 3 autres machines SYS j'ai en wget du même fichier :


Connexion vers proof.ovh.net|2001:41d0:2:876a::1|:80... connecté.
requête HTTP transmise, en attente de la réponse... 200 OK
Longueur: 10737418240 (10G) [application/octet-stream]
Sauvegarde en : «/dev/null»

100%[===================================>] 10 737 418 240 106M/s ds 97s

2014-03-01 22:11:11 (105 MB/s) - «/dev/null» sauvegardé [10737418240/10737418240]

Terminé --2014-03-01 22:11:11--
Téléchargé(s): 1 fichiers, 10G en 1m 37s (105 MB/s)

(Tous à 105MB/s environ)

____________________________________________

Test de 3 co machine A vers la machine B, C ou D :

(avec dd bs=1M count=10 if=/dev/zero | nc IP 2000)

10485760 octets (10 MB) copiés, 14,6854 s, 714 kB/s

(Notez que la connexion est monté à 700 kB/s vue que j'ai fais ces tests tjrs en prod mais avec bcp moins de personne à ce moment là)

Résultat sur la machine X qui est chez un concurrent :

10485760 octets (10 MB) copiés, 32,9017 s, 319 kB/s

Voilà j'ai plus qu'a faire les test en rescue, et la nuit quand il n'y a aucun client.

Technogeek
01/03/2014, 12h15
Salut, merci beaucoup ! Je test tout ça, il faudra que je fasse le test en rescue pour le support aussi (=_=) etc...

Je donnerai un retour dès que possible

phil
01/03/2014, 11h17
Bonjour

Je ne suis pas expert en BDD et j'ai un peu du mal à comprendre ton architecture.

Mais déjà je peux te dire que ton test de la bande passante avec SCP est une mauvaise idée car tu testes aussi
  • ton CPU car derrière le SCP tu as du SSH avec de l’encryption
  • ton DD car tu as probablement écrit le fichier dessus


Pour ne tester que ta bande passante
Utilise netcat pour transférer sur le réseau et utilises un pipe avec dd pour faire tes io dans la mémoire
Code:
Sur le serveur A: ~# dd bs=1M count=10 if=/dev/zero | nc @IP_serveur_B 20000
Sur le serveur B: ~# nc -l -p 20000 | dd of=/dev/null
Bien évidemment, il faut que le port 20000 dans mon exemple soit ouvert sur le serveur B. Ici dd va prendre 10 blocks de 1Mo et envoyer ça dans netcat qui va l'envoyer sur le serveur B et ça partira direct à la poubelle. Bilan tu ne testes que la bande passante

Autre test de bande passante, ici depuis mon SYS
Code:
root@nsxxxxxx:~# wget http://proof.ovh.net/files/10Gio.dat -O /dev/null
--2014-03-01 12:04:56--  http://proof.ovh.net/files/10Gio.dat
Resolving proof.ovh.net (proof.ovh.net)... 2001:41d0:2:876a::1, 188.165.12.106
Connecting to proof.ovh.net (proof.ovh.net)|2001:41d0:2:876a::1|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 10737418240 (10G) [application/octet-stream]
Saving to: `/dev/null'

100%[=======================================================================================================>] 10,737,418,240  107M/s   in 97s     

2014-03-01 12:06:33 (106 MB/s) - `/dev/null' saved [10737418240/10737418240]
En fait, avec les SYS tu as une interface de 1Gbps et OVH te garanti 200Mbps de bande passante. Mais, surtout sur le réseau interne, ce n'est normalement pas un problème d'atteindre le Gbps.

Vérifie aussi que ton interface a bien négocié à 1Gbps. Ce problème est déjà arrivé à quelqu'un d'autre.
Code:
:~# ethtool eth0 | grep Speed
	Speed: 1000Mb/s
Pour tester les I/O disques
Code:
write: dd bs=1M count=1024 if=/dev/zero of=test conv=fdatasync 
read : dd bs=1M count=1024 if=test of=/dev/null
Bref, si tu as réellement un problème de bande passante, normalement les tests précédents devraient le montrer. Et effectivement, si ton interface monte à 1Gbps et que tu ne communiques pas avec netcat à au moins 200Mbps, tu peux légitimement ouvrir un ticket auprès d'OVH.

En remarque. Je ne comprends pas très bien ton utilisation des BDD master/slave. Pourquoi ton master sert-il de proxy ? Généralement, un tel mécanisme est intéressant quand ta BDD a un fort taux de lecture et assez peu d'écriture. Il te faut alors une appli qui est capable de load-balancer "intelligemment" les lectures vers les slaves et les écritures sur la master.

Bon courage

Philippe

Technogeek
28/02/2014, 16h05
Bonjour,

Voici un C/C du début de l'histoire, j'ai trouver quelques nouveaux truc je colle donc ça et fini l'histoire après

__________________________________________________ _____

En gros j'ai 4 serveur, on va les nommer A, B, C, D ou A est le serveur maître, il réplique une petite base (90ko) sur les serveurs B, C, D ... donc là pas de problème, ça ce replique tout ça.

En journée, quand ya plus de traffic, le liens entre A et le serveur B, C, ou D est extrêmement lent, avec des erreur du TYPE "Lost connection to MySQL server at 'reading authorization packet', system error: 0 "Internal error/check (Not system error)" --> Seulement quand c'est le serveur A vers B, C ou D. J'ai fais des tests entre C et D, B et C, etc, aucun problème ça met 0.01s à exec la requête.

Par contre la requête du serveur A vers B, C OU D prend du temps (quand elle marche et que y'a pas l'erreur que j'ai dit précédemment).
Un simple SHOW DATABASES par exemple, met 1 seconde puis 5 seconde puis 7 voir 8 et enfin l'erreur.

Le load average de la machine A est correcte, quand je regarde le processlist pas de souçis...
Quand je suis en LOCALHOST de la machine A n'ai absolument AUCUN bug et c'est très rapide. (Je rappel que la machine A n'arrive même pas à faire un SHOW DATABASES; en moins de 7 secondes sur la machine B, C ou D en journée alors que ça prend 0,01s entre la machine B & C, C & D, ou encore B & D.)

__________________________________________________ _______

Bref j'ai continuer un peu mes recherches, et il semblerait que ça vienne bien de la connectivité, en effet un SCP d'un fichier entre la machine A et B, C ou D va à environ 500 Ko/s en journée (Comme dit la nuit aucun problème ça va à (15/20Mo/s) ce qui me fait dire que c'est bien un problème de connectivité et rien à voir avec MySQL ! (Alors que j'ai cru depuis le début que c'était MySQL qui plantait lammentablement).

Pour rappel mes 4 machiens sont chez SYS, j'ai 200 Mbits normalement sur chacune, donc voilà un graph du panel SYS en heure de pointe. Je rappel ma topologie aussi, le serveur A fait proxy entre B, C et D, le serveur A envoi / reçoit donc le DOUBLE d'informations.

Upload de la machine A en heure de pointe: http://img580.imageshack.us/img580/1122/5yz0.png
Download de la machine A en heure de pointe: http://i.imgur.com/2MPHgEk.png

Upload de la machine B, C & D en heure de pointe (en effet toutes ces machines ont environ le même résultat) : http://i.imgur.com/Tn4cczb.png et en DL pour celles-ci c'est moitié moins.

Voilà je suis donc très loin des 200 Mbits pour la machine A, je ne comprends donc pas pourquoi c'est aussi lent... en journée ! (Ah oui aussi, moi et mes clients n'ont strictement AUCUN problème, la connexion entre moi et l'appli n'a pas de souçis ça à l'air d'être assez rapide sans problème). Le problème n'a pas l'air de venir de la connexion Externe -> Machine A. (Enfin faudrais que je test avec une machine externe en fait...))

Cordialement !