OVHcloud Web Hosting Status

Current status
Legend
  • Operational
  • Degraded performance
  • Partial Outage
  • Major Outage
  • Under maintenance
le telechargement de grand fichiers
Scheduled Maintenance Report for Web Cloud
Completed
Certains clients nous remontent de problemes
de telechargement de grands fichiers dans le
cas où le debit est très faible. C'est à dire
que le telechargement avance mais très très
doucement, puis d'un coup il se coupe.

Nous avons modifié un peu la configuration
de notre infra afin d'essayer de l'adapter
au besoin.

On attend maintenant le feedback de clients
pour voir si ça fixe le probleme ou pas
encore (on n'a pas de probleme lors qu'on
utilise le FAI OVH ça arrive quand c'est
un FAI exterieur à notre reseau).

Update(s):

Date: 2012-11-26 08:11:32 UTC
Le soucis a été résolut suite à notre dernière modification.

Date: 2012-11-20 19:01:17 UTC
Nous venons de changer le routage vers les ACE,
ainsi qu'un paramètre de sécurité sur les ACE.

Nous avons déjà un feedback positif. Nous attendons
d'autres retours avant de crier victoire


Date: 2012-11-14 17:00:56 UTC
Les coupures ont été identifiées et isolées.

Nous avons ajusté les paramètres de nos
répartiteurs en conséquence.

Nous attendons les feedbacks

Date: 2012-11-12 09:25:43 UTC
Le probleme se situe entre les AX et les ACE
et la mauvaise gestion de timeout par l'AX.
Le visiteur lance un telechargement d'un gros
fichier, la requete va sur l'AX, l'AX fait la
requete sur l'ACE, l'ACE sur le serveur et
le resultat est retourné vers le visiteur.
Le telechargement entre AX/ACE/serveur se
fait rapidement. Puis entre le visiteur et
l'AX ça depend. ce qui fait que la connexion
entre AX/ACE ne fait rien pendant un certain
temps alors que le telechargement continue
sur l'AX. Au bout d'un certain temps il y a
un timeout entre AX/ACE qui provoque la
coupure de la connexion vers le visiteur.



Date: 2012-11-12 08:28:03 UTC
d'apres nos tests, nous avons trouvé les parametres qui
fonctionnent correctement et il n'y a plus de problemes.

nous allons donc maintenant cherché les parametres qui
annulent les effets secondaire du nouveau parametrage.

Date: 2012-11-11 21:06:16 UTC
un autre paramétrage

on attend les feedbacks.

Date: 2012-11-08 05:47:46 UTC
une autre modification d'un paramètre.

on attend les feedbacks.

Date: 2012-11-07 22:53:02 UTC
Le problème ne vient pas du serveur.
Nous continuons nos investigations...

Pour les curieux, le serveur reçoit un: ECONNRESET (Connection reset by peer):

select(0, NULL, NULL, NULL, {0, 1525}) = 0 (Timeout)
_llseek(37, 43090432, [43090432], SEEK_SET) = 0
read(37, \"E\\2234\\320\\3236\\rf\\340\\241znK(\\247\\310(6@r\\23\\243\\242\\206E\\347\\343\\340{\\375\\206\\2\"..., 8000) = 8000
gettimeofday({1352326283, 184650}, NULL) = 0
writev(36, [{\"E\\2234\\320\\3236\\rf\\340\\241znK(\\247\\310(6@r\\23\\243\\242\\206E\\347\\343\\340{\\375\\206\\2\"..., 8000}], 1) = 8000
select(0, NULL, NULL, NULL, {0, 1525}) = 0 (Timeout)
_llseek(37, 43098432, [43098432], SEEK_SET) = 0
read(37, \"\\304\\347\\245\\275\\20IC\\366\\345\\206\\355On\\346A\\335\\267*\\260\\362W\\324\\262\\30\\305vH\\306
gettimeofday({1352326283, 317615}, NULL) = 0
times({tms_utime=1612, tms_stime=3704, tms_cutime=0, tms_cstime=0}) = 1850213436
gettimeofday({1352326283, 319236}, NULL) = 0
close(36) = 0
close(37) = 0
gettimeofday({1352326283, 319913}, NULL) = 0
Posted Nov 07, 2012 - 20:26 UTC
This scheduled maintenance affected: Web Hosting || Datacenter GRA (Cluster002, Cluster003, Cluster006, Cluster007, Cluster011, Cluster012, Cluster013, Cluster014, Cluster015, Cluster017, Cluster020, Cluster021, Cluster023, Cluster024, Cluster025, Cluster026, Cluster027, Cluster028, Cluster029, Cluster030, Cluster031).