Bloquage de ma base de données sans préavis

[Maximet]

Bonjour,

J'ai souscris il y a un mois un 90PLAn chez OVH.

Je possède, comme de nombreux sites mutualisés, un forum PHPBB.

Celui-ci fonctionne bien, il y a 4500 inscrits.

J'ai reçu hier un mail qui m'informe du blocage en écriture de ma BDD du forum, car celle-ci dépasse le quota RECOMMANDE. Donc, le forum est inaccessible.

Il n'y a eu aucun mail préalable, la base a été BLOQUE d'une minute à l'autre.

Je viens de contacter le service technique qui m'informe qu'il est IMPOSSIBLE de réactiver ma base (le temps que je réfléchisse à une solution) au moins pour le week-end. IMPOSSIBLE ?

Par ailleurs, le technicien ne m'a indiqué aucune solution, aucune offre de remplacement. En gros, "ben c'est comme ça, y'a rien à faire". L'appel a eu lieu à 16H37.

Est-il normal de bloquer les bases de données d'utilisateurs de "PLAN" sans leur proposer une solution de remplacement, comme le SQLPLAN qui vient d'être suspendu ! ?

J'ai quitté SIVIT pour OVH à cause du service technique et de la qualité de service.

Je résume donc. Que l'on soit en 90plan ou en 720 ou XXL plan, les BDD ne doivent pas dépasser 50mo. Je n'ose imaginer le nombre de forums qui ont sauté depuis deux jours.

Je rappelle par ailleurs que c'est une taille RECOMMANDEE et pas OBLIGATOIRE. Le technicien m'a donc indiqué que la mention allait juste être changée sur la page de l'offre. Il l'a dit ! Mais je n'ai pas signé pour ça.

Je vous adresse donc ici, puisqu'il semble impossible d'obtenir des infos du service technique l'adresse de mon site le nom de la base incriminée.

allez-brest.com
base: allezbreab

Merci de votre réponse.

De plus, voici un lien avec des personnes victimes du même problème. http://www.webrankinfo.com/forums/viewtopic_69808.htm

Bonjour,

des precisions:
- la base allezbreab est en fonctionnement. vous pouvez faire
les select et les delete sans probleme.
- vous ne pouvez pas ajouter des informations ou les modifier.
- la taille de la base est recommandée à 40Mo. si vous depassez
ça risque de ne pas fonctionner correctement et tiens ça
ne marche pas correctement ... mais ça marche encore.
je prefere d'être à l'origine du "non fonctionnement total"
que des problemes graves qui vont apparaitre si on ne vous
arrete pas à temps
- votre base fait 111Mo, soit 3 fois trop. elle degrade le
service à tous les clients qui respectent les quotas.
- vous pouvez effacer les informations en trop, vous pouvez
recuperer toutes les données via un dump puis dés que vous
êtes dans la quota, 1 clic dans le manager et en moins de
10 minutes le robot verifie le quota et remet la base en
fonctionnement totale si vous respectez le quota.
- vous avez la possibilitée de passer à l'offre superieure
mais avec la taille de votre base 120Mo, c'est le dédié.
on proposait un sqlplan jadis, mais:
- les bases sql necessitent beaucoup de CPU et finalement
même en mettant en production de bi cpu dual on s'en
sort pas avec 50-70 bases par serveur ... (!!!!)
nous avons mis en production 10 serveurs et on a décidé
d'arreter la massacre d'autant plus que les clients
n'arretaient pas de raler que la qualité n'y est pas
alors qu'ils paient si cher le serveur sqlplan ...
(cf les messages sur le forum).
- et donc on le proposait en perdant de l'argent et
beaucoup ... et en ayant plein de client insatisfaits
- la solution au probleme: le client doit passer sur le
serveur dédié. il a son CPU, sa RAM et va vite constater
le vrai cout de l'hébergement et ne pas nous demander
la lune pour pas cher. désolé j'essaie proposer l'impossible
mais là je jette l'eponge.

Octave

[malibard]

Envoyé par Maximet

J'ai quitté SIVIT pour OVH à cause du service technique et de la qualité de service.

eh je peux te dire que ovh n'est pas tres recommandé pour les bdd

et puis le support technique c'est le minimum ! moi je veux bien bossé chez , ça doit etre tranquille de pas reponse et de repondre a coté !

[Maximet]

Je comprend tout à fait les raisons que vous énoncez.

Mais,
D'une, vous bloquez les bdd partiellement sans préavis.
De deux, je n'ose pas imaginer le nombre de retour que vous avez eu, surtout que pour des forums, souvent un mutualisé suffit.
De trois, patienter 24 heures pour s'entendre dire par mail, je cite: "Vous deverez encore purger svp". C'est la grande classe.

Bref ... Solution très pratique que de purger un forum

Maximet <Maximet.2njs1n@no-mx.forums.ovh.com> a écrit:
>
> Je comprend tout à fait les raisons que vous énoncez.
>
> Mais,
> D'une, vous bloquez les bdd partiellement sans préavis.
> De deux, je n'ose pas imaginer le nombre de retour que vous avez eu,

nous avons fermé 0.362% des bases hébergées sur les serveurs
MySQL5 de 90plan dont la vôtre. ces 0.362% des bases prennent
20-50% de resources. grâce à la mutualisation il est possible
de proposer le service pas cher et de qualité mais il faut
respecter ceux qui paie et n'utilisent pas vraiment le service
(et donc vous permettent de payer peu et avoir beaucoup)
en leur proposer le minimum: la qualité.

> surtout que pour des forums, souvent un mutualisé suffit.

oui souvent.

> De trois, patienter 24 heures pour s'entendre dire par mail, je cite:
> "Vous deverez encore purger svp". C'est la grande classe.

vous payez peu, vous utilisez beaucoup. je comprends que vous
aimeriez avoir la reponse du style "allez encore", mais ce
n'est pas possible.

> Bref ... Solution très pratique que de purger un forum

tout a un prix: dédié ... chez ovh ou un concurent ... peu
importe mais croire que vous allez pouvoir faire du forum
avec autant de données, à longterme en payant moins de
10Euro/mois c'est se mentir.

[Maximet]

Je comprend tout à fait.

MAIS

J'ai signé un contrat m'indiquant que je disposais de base de données de 40MO recommandé.

En aucun cas, une BDD de 40mo OLIBATOIRE.

Cette mention recommandée est présente chez tous les hébergeurs et indique ce ... qu'elle veut dire.

Ensuite, que certains profitent du système mutualisé, c'est la dure loi de la jungle. Je n'ai pas l'impression d'en abuser, je suis les règles, tout simplement. Je n'utilise que peu d'espace disque, je n'ai pas besoin de disque dur dédié.

On a pas été prevenu que l'offre SQL PLAN a disparu ? Les clients
possédant cette offre peuvent toujours renouveller ?


oles@ovh.net a écrit :
> Bonjour,
>
> des precisions:
> - la base allezbreab est en fonctionnement. vous pouvez faire
> les select et les delete sans probleme.
> - vous ne pouvez pas ajouter des informations ou les modifier.
> - la taille de la base est recommandée à 40Mo. si vous depassez
> ça risque de ne pas fonctionner correctement et tiens ça
> ne marche pas correctement ... mais ça marche encore.
> je prefere d'être à l'origine du "non fonctionnement total"
> que des problemes graves qui vont apparaitre si on ne vous
> arrete pas à temps
> - votre base fait 111Mo, soit 3 fois trop. elle degrade le
> service à tous les clients qui respectent les quotas.
> - vous pouvez effacer les informations en trop, vous pouvez
> recuperer toutes les données via un dump puis dés que vous
> êtes dans la quota, 1 clic dans le manager et en moins de
> 10 minutes le robot verifie le quota et remet la base en
> fonctionnement totale si vous respectez le quota.
> - vous avez la possibilitée de passer à l'offre superieure
> mais avec la taille de votre base 120Mo, c'est le dédié.
> on proposait un sqlplan jadis, mais:
> - les bases sql necessitent beaucoup de CPU et finalement
> même en mettant en production de bi cpu dual on s'en
> sort pas avec 50-70 bases par serveur ... (!!!!)
> nous avons mis en production 10 serveurs et on a décidé
> d'arreter la massacre d'autant plus que les clients
> n'arretaient pas de raler que la qualité n'y est pas
> alors qu'ils paient si cher le serveur sqlplan ...
> (cf les messages sur le forum).
> - et donc on le proposait en perdant de l'argent et
> beaucoup ... et en ayant plein de client insatisfaits
> - la solution au probleme: le client doit passer sur le
> serveur dédié. il a son CPU, sa RAM et va vite constater
> le vrai cout de l'hébergement et ne pas nous demander
> la lune pour pas cher. désolé j'essaie proposer l'impossible
> mais là je jette l'eponge.
>
> Octave
>

[RaphAstronome]

Déjà n'utilise pas phpbb si tu as un forum simple, sans trucs inutile, et surtout sans recherche (utilise google) alors tu peu peut être faire tenir ton forum.

Il est aussi possible de supprimer les anciens sujets de la et BDD et les mettre en html statique si tu veux un historique complet et là tu as presque ... 900 Mo . Arrange toi pour etre à la moitié de l'éspace recommandé, c'est tout a fait possible, ca te mettra de la marge.

PS : n'oublie pas des anti-flood aussi.

Edit :

En aucun cas, une BDD de 40mo OLIBATOIRE.

Tu peux aller un peu plus loin mais tu te rapproche alors de la limite "dure" qui est je crois à 2 fois la taille recommandée.
Il faut toujours prévoir une bonne marge.

Maximet <Maximet.2njtwb@no-mx.forums.ovh.com> a écrit:
>
> Je comprend tout à fait.
>
> MAIS
>
> J'ai signé un contrat m'indiquant que je disposais de base de données
> de 40MO *recommandé. *
>
> EN AUCUN CAS, UNE BDD DE 40MO OLIBATOIRE.

ok. on joue sur les mots.

<mode je joue sur les mots>
ovh vous recommande de ne pas depasser 40Mo. si ça depasse 40Mo
ovh ne repond plus à rien. et si on suit l'histoire de votre base
elle a bien fonctionné jusqu'au là et là vous avez plus que 40Mo
et ... ça ne fonctionne plus. voilà ce qu'il arrive lorsqu'on ne
suit pas nos recommandations. et c'est pourquoi on recommande de
ne pas depasser 40Mo, pour justement eviter ce genre des problemes.
si vous diminuez la base à moins de 40Mo ça refonctionnera, testez
vous verrez. comme quoi nos recommandations ont un sens et si vous
suivez votre base n'aura pas de probleme.
</mode je joue sur les mots>

> Cette mention recommandée est présente chez tous les hébergeurs et
> indique ce ... qu'elle veut dire.
>
> Ensuite, que certains profitent du système mutualisé, c'est la dure loi
> de la jungle.

la jungle c'est pas chez ovh. chez ovh il y a moi qui regle le flux
pourque chacun en ait pour son argent. j'ai un certain sens de "juste"
(au sens de justice). ça plait ou pas. en tout cas ceux qui paient
proportionellement beaucoup par rapport à ce qu'ils utilisent n'auront
pas de probleme. et ceux qui paie proportionnelement pas assez par
rapport à ceux qu'ils utilisent réellement vont raler sur le forum
et je leur repondrai ce que je viens de poster.

par contre il ne s'agit pas de ta base en general mais le comportement
de l'ensemble des clients qui vont (sans savoir ou en connaissance de
cause) au delà de nos recommandations. je suis sûr que si je remets
ta base ça fonctionnera, mais que me diront les autres clients qui
vont avoir la base en selectonly et vont vouloir le même traitement ?
je ne peux pas traiter votre base autrement que toutes les bases des
autres clients et si je remets toutes les bases des autres clients,
tous les clients auront des problemes comme hier à la même heure:
http://smokeping.ovh.net/ovh-server-...an.mysql5-4-90
or aujourd'hui je n'ai plus de pic à 500ms en reponse comme hier,
je reste à 100ms. et donc je conclue que votre base ainsi que les
autres 0.369%-votre base sont à l'origine des surcharges sur le
serveurs que l'ensemble des clients ont pu constaté hier.

j'en conviens que le traitement n'est pas encore au point. dans un
futur proche vous receverez:
- d'abord les emails avec les requetes qui prennent plus que 10secondes
- les emails que vous arrivez à 90% du quota
- l'email de passage en selectonly

Mais en comparaison à la semaine passée où j'ai fermé d'autres bases,
vous avez la possibilitée aujourd'hui de reouvrir la base si vous
passez en desous de quota recommandé. la semaine passée ce n'était
pas possible, c'est pourquoi j'ai reouvers toutes les bases (suite
à un email d'un client honete qui m'a descrit sa situation et sa
bonne foi ou plustôt son incompetance dans la resolution du probleme,
ça m'a fait remettre en cause l'ensemble des actions que j'ai mis
des semaines à preparer, mais c'est comme ça, on ferme sa tronche
et on reouvert même si le client depasse). cette semaine ce n'est
pas la même chose, mais je reste ouvert aux propositions.

> Je n'ai pas l'impression d'en abuser, je suis les règles,
> tout simplement. Je n'utilise que peu d'espace disque, je n'ai pas
> besoin de disque dur dédié.

il ne s'agit pas d'espace disque mais d'utilisation de resources sql.
ça se traduit bien en espace disque utilisé puisque c'est un tout:
la ram utilisé, le temps d'une requete sql dans une grosse base,
l'espace disque et donc les access disque et donc les perfs de la
machine en general.

On a pas été prevenu que l'offre SQL PLAN a disparu ? Les clients
possédant cette offre peuvent toujours renouveller ?



oles@ovh.net a écrit :
> Maximet <Maximet.2njtwb@no-mx.forums.ovh.com> a écrit:
>> Je comprend tout à fait.
>>
>> MAIS
>>
>> J'ai signé un contrat m'indiquant que je disposais de base de données
>> de 40MO *recommandé. *
>>
>> EN AUCUN CAS, UNE BDD DE 40MO OLIBATOIRE.
>
> ok. on joue sur les mots.
>
> <mode je joue sur les mots>
> ovh vous recommande de ne pas depasser 40Mo. si ça depasse 40Mo
> ovh ne repond plus à rien. et si on suit l'histoire de votre base
> elle a bien fonctionné jusqu'au là et là vous avez plus que 40Mo
> et ... ça ne fonctionne plus. voilà ce qu'il arrive lorsqu'on ne
> suit pas nos recommandations. et c'est pourquoi on recommande de
> ne pas depasser 40Mo, pour justement eviter ce genre des problemes.
> si vous diminuez la base à moins de 40Mo ça refonctionnera, testez
> vous verrez. comme quoi nos recommandations ont un sens et si vous
> suivez votre base n'aura pas de probleme.
> </mode je joue sur les mots>
>
>> Cette mention recommandée est présente chez tous les hébergeurs et
>> indique ce ... qu'elle veut dire.
>>
>> Ensuite, que certains profitent du système mutualisé, c'est la dure loi
>> de la jungle.
>
> la jungle c'est pas chez ovh. chez ovh il y a moi qui regle le flux
> pourque chacun en ait pour son argent. j'ai un certain sens de "juste"
> (au sens de justice). ça plait ou pas. en tout cas ceux qui paient
> proportionellement beaucoup par rapport à ce qu'ils utilisent n'auront
> pas de probleme. et ceux qui paie proportionnelement pas assez par
> rapport à ceux qu'ils utilisent réellement vont raler sur le forum
> et je leur repondrai ce que je viens de poster.
>
> par contre il ne s'agit pas de ta base en general mais le comportement
> de l'ensemble des clients qui vont (sans savoir ou en connaissance de
> cause) au delà de nos recommandations. je suis sûr que si je remets
> ta base ça fonctionnera, mais que me diront les autres clients qui
> vont avoir la base en selectonly et vont vouloir le même traitement ?
> je ne peux pas traiter votre base autrement que toutes les bases des
> autres clients et si je remets toutes les bases des autres clients,
> tous les clients auront des problemes comme hier à la même heure:
> http://smokeping.ovh.net/ovh-server-...an.mysql5-4-90
> or aujourd'hui je n'ai plus de pic à 500ms en reponse comme hier,
> je reste à 100ms. et donc je conclue que votre base ainsi que les
> autres 0.369%-votre base sont à l'origine des surcharges sur le
> serveurs que l'ensemble des clients ont pu constaté hier.
>
> j'en conviens que le traitement n'est pas encore au point. dans un
> futur proche vous receverez:
> - d'abord les emails avec les requetes qui prennent plus que 10secondes
> - les emails que vous arrivez à 90% du quota
> - l'email de passage en selectonly
>
> Mais en comparaison à la semaine passée où j'ai fermé d'autres bases,
> vous avez la possibilitée aujourd'hui de reouvrir la base si vous
> passez en desous de quota recommandé. la semaine passée ce n'était
> pas possible, c'est pourquoi j'ai reouvers toutes les bases (suite
> à un email d'un client honete qui m'a descrit sa situation et sa
> bonne foi ou plustôt son incompetance dans la resolution du probleme,
> ça m'a fait remettre en cause l'ensemble des actions que j'ai mis
> des semaines à preparer, mais c'est comme ça, on ferme sa tronche
> et on reouvert même si le client depasse). cette semaine ce n'est
> pas la même chose, mais je reste ouvert aux propositions.
>
>> Je n'ai pas l'impression d'en abuser, je suis les règles,
>> tout simplement. Je n'utilise que peu d'espace disque, je n'ai pas
>> besoin de disque dur dédié.
>
> il ne s'agit pas d'espace disque mais d'utilisation de resources sql.
> ça se traduit bien en espace disque utilisé puisque c'est un tout:
> la ram utilisé, le temps d'une requete sql dans une grosse base,
> l'espace disque et donc les access disque et donc les perfs de la
> machine en general.
>
>
>