L'offre SQL Privé d'OVH

Fab le Fou · 20 Août 2009

Bonjour à tous,

Je cherche à avoir des retours d'utilisateurs concernant l'offre "SQL Privé" d'OVH : http://www.ovh.com/fr/hebergement_mutualise/sql_prive.xml

Dans notre cas, il s'agirait de déplacer notre base de données principale pour en suite l'appeler à partir de nos 2 dédiés.

a++,

Fab

rtb · 21 Août 2009

Cette offre semble bien intéressante en effet, par contre je n'ai pas testé.

Diabolik34 · 21 Août 2009

En effet, ça a l'air assez intéressant!
S'il y en a qui s'y connaissent : avec l'offre basique et 128Mo de RAM, quelles peuvent-être les limites?

adminblue · 23 Août 2009

Diabolik34 a dit:
S'il y en a qui s'y connaissent : avec l'offre basique et 128Mo de RAM, quelles peuvent-être les limites?

Question complexe, je vais essayer d'expliquer en termes simples. Puis de répondre plus spécifiquement à la question concernant le SQL Privé OVH.

MySQL est un système qui travaille en réalité sur disque, aussi surprenant que ce soit, MAIS où la mémoire disponible joue un rôle absolument essentiel pour les performances : en effet la RAM sert de cache pour le disque, de manière très sophistiquée (ce n'est pas un simple buffer d'écriture/lecture) , en outre, évidemment, la RAM constitue l'espace de travail privilégié pour les performances.

Cette organisation permet DANS L'ABSOLU à MySQL de traiter des bases de données énormes avec une RAM bien inférieure à la taille des données MAIS ce sont les performances qui sont très directement affectées par la RAM disponible.

En effet, quand une requête ("query") - c'est à dire une interrogation élémentaire, pas une "question" au sens humain - se présente au serveur MySQL, celui-ci regarde s'il dispose des éléments nécessaires en RAM pour la traiter. (C'est la notion que l'on appelle abusivement "fenêtre de données"... les éléments utiles peuvent-ils tenir ou non dans la RAM ?)

Si oui, c'est super rapide, du genre 1/20ème de seconde (et moins) à 1/10ème (environ) pour des requêtes "ordinaires". MySQL fournit donc l'information très vite au programme qui l'a demandée, et ce programme peut alors fermer la connexion avec MySQL, connexion qui est libérée pour un autre programme ou une autre interrogation. (Le nombre de connexions est limité.)

Si non, ça se gâte plus ou moins. Car MySQL est obligé d'aller chercher les éléments sur le disque. Evidemment, cela signifie aussi qu'il doit éventuellement vider la RAM de certains autres éléments qui manqueront donc pour d'autres requêtes : dommage collatéral si l'on veut. Le temps d'exécution de la requête s'en trouve affecté. De combien ?! Impossible à dire : cela dépend des performances du système disque et donc aussi de la charge du système disque en environnement multi-utilisateurs (c'est d'ailleurs le cas sur le SQL Privé OVH puisque celui-ci est un VPS), et cela dépend de ce que doit chercher et faire MySQL ET de savoir s'il peut ou non utiliser de la RAM à nouveau. Ca peut être rapide ou ça peut ramer.
Autre inconvénient : le stress sur les disques augmente beaucoup.

On ne peut pas comparer directement la taille cumulée des bases de données sur un serveur MySQL et la RAM pour dire que c'est "trop" ou "bon" ou "pas assez". Tout dépend de ce que font les bases de données. MAIS (oui, il y a beaucoup de "mais"), statistiquement, il est permis de dire que plus la taille cumulée des bases dépasse la RAM disponible, plus l'on va, progressivement (parfois brutalement), s'exposer à des ralentissements.

Ici, on peut tout simplement citer Octave, le patron d'OVH, qui définissait très bien le problème. (Il parlait des serveurs MySQL des hébergements Mutus)

si tu veux une base rapide, ta base est dans la ram. c'est un simple fait d'admin sql. sinon c'est lent.
http://forum.ovh.com/showpost.php?p=235388&postcount=28

C'est un peu extrême mais c'est ma conception de la qualité aussi, je dois l'avouer... quand c'est techniquement et financièrement possible.

Alors quid avec 128Mo de RAM ? Il n'y a pas de vérité absolue mais on peut tenter de dire les choses suivantes.

- 128Mo pour un serveur MySQL en 2009, ce n'est pas beaucoup (les applications ont augmenté leurs besoins en MySQL au cours des dernières années)

- Toutefois, 128 Mo de RAM peuvent faire fonctionner des BDD de 500Mo total par exemple... ce sont les performances qui seront en question, selon ce que font les bases. (Plus les requêtes sont aléatoires, et plus elles sont complexes, plus cela va devenir difficile, pour parler très très simplement.)

- 128 Mo ce n'est pas tout à fait 128 puisqu'il faut déduire le système, le serveur MySQL lui-même, et les logiciels annexes (il y a une sorte de FTP si je comprends bien en SQL privé (?)

- Le CPU n'est pas connu (en fait, la puissance équivalente, puisque c'est du VPS) mais ce n'est pas fondamental pour un petit serveur SQL

- Si on met deux bases de données de 50Mo chacune, ou une de 100Mo (avec toutes les réserves que j'ai faites au sujet de la comparaison RAM/taille) , tout va tenir en mémoire ou à peu près et ça devrait très bien marcher quasiment à coup sûr.

- Si on met des bases pour, par exemple, 300-400Mo, surtout s'il y en a une grosse, c'est plus aléatoire. Il faut essayer...

- Par contre, et à titre d'opinion personelle (donc je ne dis pas que c'est une vérité absolue), je suis sceptique sur le fait de bouger sur un SQL Privé de 128Mo de RAM les quelques 50 bases de données de 50Mo chacune (avec 50 connexions simultanées chacune) d'un ancien XXPlan OVH ou les 25x50Mo avec 20 connexions d'un ancien 720Plan !

Le XXPlan comportait 50 bases de 50Mo x 50 connexions chacune. Cette offre à 29,99 euros vient de disparaitre (comme toutes les offres Plans d'OVH). Le 720Plan offrait pour 14 euros : 25 bases de 50Mo avec 20 connexions chacune.
L'offre de remplacement "Premium" à 19,99 euros (donc entre les deux coûts précédents) offre 4 (quatre) bases de données : 3x200Mo, et 1x1Go avec 10 connexions chacune... et un SQL Privé de 128Mo de RAM. (Pas sûr que une base de 1Go avec 10 connexions soit une offre bien équilibrée pour du mutualisé.)
Donc si on utilisait un XXPlan de manière un peu intensive, on se retrouve avec quelque chose comme 45 bases de 50Mo et 50 connexions chacune à bouger sur un SQL Privé de 128Mo. Disons que chaque base fait en réalité en moyenne 25Mo, cela fait:
45x25= 1125Mo (1,125Go si on compte en décimal) et 45x50 connexions possibles = 2250 connexions... sur un VPS avec 128Mo de RAM totale. Pour un 720Plan, en prenant encore seulement 25Mo par base et 21 bases à bouger, ce serait quelque chose comme 25x21 = 525Mo et 21x50 = 1050 connexions.
C'est beaucoup...
Même la migration d'un ancien 240Plan (15 bases de 45Mo avec 10 connexions chacune) pose de sérieuses questions. (Et sur les offres inférieures à Prémium, le SQL privé n'est pas inclus, c'est un supplément à 6 euros HT / mois.)

- Le SQL Privé peut heureusement être upgradé : 10 € HT/mois pour 256Mo de RAM, 20 euros pour 512, 40 euros pour 1Go (mais si on arrive là, il est rationel de se poser la question d 'un petit dédié).

Mon avis personnel est que pas mal d'utilisateurs seraient avisés de considérer du 512Mo ou 256Mo dans leus études, pour un Web de qualité, avec, toutefois, toujours la possibilité d'une bonne surprise avec 128Mo.

Fab le Fou a dit:
Dans notre cas, il s'agirait de déplacer notre base de données principale pour en suite l'appeler à partir de nos 2 dédiés.

A moins que tes dédiés soient surchargés, tu devrais pouvoir faire mieux sur eux qu'avec un VPS de 128Mo de RAM, en configurant bien le serveur. Cela dépend de ce que tu fais, mais cela paraît plus logique a priori.

Diabolik34 · 24 Août 2009

réponse intéressante adminblue, je te remercie grandement d'avoir pris le temps d'écrire tout ça

seebz · 24 Août 2009

Il me semble que les SQL privés ne sont pas accessibles depuis les dédiés :?

Fab le Fou · 24 Août 2009

seebz a dit:
Il me semble que les SQL privés ne sont pas accessibles depuis les dédiés :?

C'est vrai qu'ils mettent "Nécessite : un hébergement mutualisé." mais est-ce que le mini hébergement qu'ils fournissent avec les ndd enregistrés chez eux ne suffit pas ?

Après si la bdd est ouverte aux connexions externes, les dédiés pourront sans doute s'en servir.

Merci à adminblue pour sa réponse très complète.

Diabolik34 · 24 Août 2009

Fab le Fou a dit:
C'est vrai qu'ils mettent "Nécessite : un hébergement mutualisé." mais est-ce que le mini hébergement qu'ils fournissent avec les ndd enregistrés chez eux ne suffit pas ?

c'est plutôt l'espace pour la bdd qui est vraiment petite

mims1664 · 25 Août 2009

Alors personnellement j'avais compris qu'ils s'agissait de 128 Mo de mémoire alloué à un process Mysql et non à un VPS !
Dans ce cas 128 Mo pour faire tourner un linux, un Mysql et les services qui tournent autour, j'avoue aussi que ca me fait peur.

Personnellement je me demande si je ne vais pas migrer mon 90 plan et mon Kimsuffi vers un hébergement pro ou business et me prendre un RPS.

Pensez vous qu'il soit possible d'héberger sa base de donnée sur un RPS et se connecter depuis un MUT dessus ?

seebz · 25 Août 2009

mims1664 a dit:
Pensez vous qu'il soit possible d'héberger sa base de donnée sur un RPS et se connecter depuis un MUT dessus ?

Je ne sais pas pour les RPS mais normalement, on ne peut pas accéder à un DB d'un dédié depuis un hébergement mutualisé. Je dit "normalement" car c'est ce qui semble être définit par OVH.

Dans les faits, c'est actuellement possible (j'ai encore testé il n'y a pas si longtemps que ça).. mais est-ce que ca va durer ?
Certaines personnes ont contourné le problème en utilisant un port différent.

adminblue · 25 Août 2009

Diabolik34 a dit:
réponse intéressante adminblue, je te remercie grandement d'avoir pris le temps d'écrire tout ça

Fab le Fou a dit:
Merci à adminblue pour sa réponse très complète.

Pas de quoi. J'ai juste vu le fil en explorant le forum, et comme il y a vraiment beaucoup de choses assez bizzarres qui sont dites sur les forums d'OVH au sujet des bases de données sur les nouvelles offres, je me suis dit qu'être informatif et objectif en un lieu neutre ne ferait pas de mal.

Je précise que suis client OVH, très très satisfait en dédiés. (A mon avis imbattables.) Et satisfait jusqu'ici en mutualisés (qui avaient besoin d'une évolution) mais également critique (pas négatif mais critique) vis à vis des nouvelles offres par rapport à la situation des anciens clients.

mims1664 a dit:
Alors personnellement j'avais compris qu'ils s'agissait de 128 Mo de mémoire alloué à un process Mysql et non à un VPS !
Dans ce cas 128 Mo pour faire tourner un linux, un Mysql et les services qui tournent autour, j'avoue aussi que ca me fait peur.

Ben oui, c'est un peu limite pour les performances en 2009 (avec l'usage intensif de SQL), même si c'est possible pour ce qui est de juste "fonctionner" comme je l'ai expliqué.

Mais, à titre personnel (j'exprime donc juste une opinion, pas une vérité divine) et avec mon expérience d'admin, ce qui me gêne, ce n'est pas un serveur MySQL de 128MO de RAM, parce qu"il peut très bien faire marcher des applications pas trop gourmandes. Ce qui me gêne, c'est quand une personne importante vient répondre sur le forum OVH que
"40 bases de 20Mo c'est que dale (sic) pour un sql privé de 128RAM."
Ca c'est une réponse à l'emporte-pièce, à mon humble avis. (Surtout quand on a dit quelque chose d"infiniment plus sensé des mois auparavant, sur le fait d'avoir les bases en RAM, comme cité dans mon premier message.) Et ce qui est ennuyeux c'est que les clients mutualisés n'ont en général pas la formation pour interpréter et filtrer de telles infos.

Je crois qu'OVH voulait limiter son offre SQL en standard et cela peut se comprendre, car les bases MySQL des mutualisés "Plans" OVH marchaient (et marchent) TRES bien, et cela devait coûter cher. Que cela n'arrange pas l'utilisateur actuel est une autre question. (Le nombre de bases disponibles en standard s'est effondré mais la capacité a augmenté, pas toujours de manière équilibrée à mon avis, mais augmenté. Donc si vous utilisez peu de bases, c'est très bien. Si vous en utilisiez davantage, ou avec plus de 10 connexions, c'est très dur.)
En revanche, je pense personnellement que suggérer un peu que tout ce qui ne tiendra plus en standard peut être transféré sur un SQL Privé de 128Mo, c'est assez dangeureux. Du coup, OVH a aussi introduit, après de vives critiques, des offres de bases optionnelles par packs mais l'addition monte vraiment très vite.

mims1664 a dit:
Personnellement je me demande si je ne vais pas migrer mon 90 plan et mon Kimsuffi vers un hébergement pro ou business et me prendre un RPS.

Les RPS c'est fini le 14 septembre, et il semble (?) que l'on ne pourra plus upgrader non plus. Voir, avec toutes réserves d'usage (les titres sont ceux affichés sur les forums OVH) :

Vos RPS vont disparaitre et on ne vous a pas prévenu
http://forum.ovh.com/showthread.php?t=50231

RPS Mutu-Pro Gameplan VPS
http://forum.ovh.com/showthread.php?t=49747&highlight=Oles+RPS*

Performances du RPS en déclin ?
http://forum.ovh.com/showthread.php?t=50392

Migrer des anciens mutualisés aux nouveaux peut poser des problèmes ardus aux utilisateurs de 90Plan, 240Plan, 720Plan, et XXPlan SI ils utilisaient plus de 4 bases de données, ou plus de 10 connexions par base (720Plan, XXPlan), ou plus de 100 adresses email (limite standard de l'offre "Pro" maintenant) ou 1000 (limite Business, Premium). Pour d'autres, c'est excellent, par exemple les utilisateurs d'hébergement 300GP (qui, il est vrai, était peu intéressant par rapport à un 90Plan).

Mais l'analyse des possibles migrations chez OVH, c'est off-topic ! Avec d'autres utilisateurs, on a établi pour nous des documents listant les solutions de "migrations" possibles, avec les options à prendre ou non en fonction des cas, et leur coûts. Si cela intéresse quelqu'un, on peut les poster dans un autre fil.

seebz a dit:
mims1664 a dit:

Pensez vous qu'il soit possible d'héberger sa base de donnée sur un RPS et se connecter depuis un MUT dessus ?

Cliquez pour agrandir...

Je ne sais pas pour les RPS mais normalement, on ne peut pas accéder à un DB d'un dédié depuis un hébergement mutualisé. Je dit "normalement" car c'est ce qui semble être définit par OVH.

Dans les faits, c'est actuellement possible (j'ai encore testé il n'y a pas si longtemps que ça).. mais est-ce que ca va durer ?
Certaines personnes ont contourné le problème en utilisant un port différent.

Seebz a raison. Normalement c'est non mais... il y a un truc (parfois cité par la hot line)... ne le dis pas trop fort STP parce qu'on voudrait bien le garder !

En fait, je crois que beaucoup de clients partiraient si le truc n'était plus possible.

A mon avis, la politique de connexions externes vers MySQL est assez antique chez OVH, voire peu compréhensible. On pourrait à la rigueur comprendre que l'on ne puisse pas se connecter directement depuis une machine extérieure vers un SQL mutualisé, mais depuis un serveur OVH sur le même réseau, c'est déjà plus contestable. Mais, surtout, cela fait des années que d'autres hébergeurs offrent la possibilité de connexions directes depuis l'extérieur avec, dans leur panneau de contôle, la sécurisation de cette connexion en filtrant par IP ou domaine, etc. (Planethoster, HostMonster, Servage,..), et en limitant les droits MySQL, et leurs réseaux ne sont pas des gouffres d'insécurité non plus.

nico78 · 26 Août 2009

adminblue a dit:
Migrer des anciens mutualisés aux nouveaux peut poser des problèmes ardus aux utilisateurs de 90Plan, 240Plan, 720Plan, et XXPlan SI ils utilisaient plus de 4 bases de données, ou plus de 10 connexions par base (720Plan, XXPlan), ou plus de 100 adresses email (limite standard de l'offre "Pro" maintenant) ou 1000 (limite Business, Premium). Pour d'autres, c'est excellent, par exemple les utilisateurs d'hébergement 300GP (qui, il est vrai, était peu intéressant par rapport à un 90Plan).

Mais l'analyse des possibles migrations chez OVH, c'est off-topic ! Avec d'autres utilisateurs, on a établi pour nous des documents listant les solutions de "migrations" possibles, avec les options à prendre ou non en fonction des cas, et leur coûts. Si cela intéresse quelqu'un, on peut les poster dans un autre fil.

J'ai fait les mêmes constatations quand j'ai appris les changements d'offres ! Cela a un peu gâché la fin de mes vacances. Et encore leurs offres ont évolué car au début on avait la possibilité d’avoir je crois que 10 ou 50 multi domaines au lieu des 1000 des 720plan et xxplan !

J'ai un 720plan et un xxlplan, et effectivement, je ne sais pas comment je vais pouvoir faire fonctionner mes bases sur un 128m.

Le total de mes base fait 120mo (sur le 720plan) et 130 mo (sur le xxlplan), donc pour moi, je pense prendre un sql privé au minium 256 mo ou 512 Mo. Mais comme tu l’as dit, ovh ne donne pas d’info sur les performances !

Je suis moi aussi client chez ovh depuis de nombreuse années, mais là, je trouve qu’ils font un peu fort de modifier les offres sans prévenir et d’offrir des offres moins intéressante surtout pour ceux qui avaient des 720plan et xxlpan.

Je sui intéressé par ton doc

lg · 26 Août 2009

Bonjour !
Merci de ces infos...n'ayant pas les connaissances suffisantes en administration serveur, j'avoue que la multitude des interventions en tous sens tant du management OVH que des utilisateurs me faisait tourner la tête...et m'amenait à chercher une solution plus clair et simple...ailleurs....
Les quelques points que tu as soulevés sur le sql privé ont leurs importances..et perso ayant un 240 plan je ne suis pas sur de trouver mon compte avec les nouvelles formules....

Ohax · 26 Août 2009

C'est une solution intéressante, mais j'attends les retours sur les performances et surtout les possibilités de sauvegarde.

Sinon... Le cpu... Il y a des limites ?

adminblue · 26 Août 2009

nico78 a dit:
J'ai un 720plan et un xxlplan, et effectivement, je ne sais pas comment je vais pouvoir faire fonctionner mes bases sur un 128m.

Le total de mes base fait 120mo (sur le 720plan) et 130 mo (sur le xxlplan), donc pour moi, je pense prendre un sql privé au minium 256 mo ou 512 Mo. Mais comme tu l’as dit, ovh ne donne pas d’info sur les performances !

Si tu te servais de beaucoup de tes bases 720Plan et XXPlan, oui, la situation est assez compliquée.

Et puis il y a quand même un truc que je ne comprends pas :

SQL Privé 512MO sur un VPS puissance CPU non connue : 20 euros par mois
SQL Privé 1Go sur un VPS puissance CPU non connue : 40 euros par mois
OVH Kimsufi 500G, vrai dédié, Celeron D/215/220 1.20+ GHz, 2 Go RAM 500Go DD, avec un Temps de réparation de 4 heures maintenant : 29,99 euros par mois
OVH Kimsufi 750G, vrai dédié, Quad Core Q6600 4x 2.40+ GHz , 4Go RAM, 750Go DD, Réparation 4 heures : 49.99 euros/mois

N'aurait-il pas été préférable d'utiliser une infrastructure Kimsufi + un backup pour base du SQL Privé?! (Le backup SQL Privé a déjà connu des ennuis exposés sur les forums OVH mais ils ont peut-être eu la poisse.)

nico78 a dit:
Je suis intéressé par ton doc

OK. On va le mettre au propre, c'est juste un fichier Excel "pour nous" actuellement.

lg a dit:
Bonjour !
Merci de ces infos...n'ayant pas les connaissances suffisantes en administration serveur, j'avoue que la multitude des interventions en tous sens tant du management OVH que des utilisateurs me faisait tourner la tête...et m'amenait à chercher une solution plus clair et simple...ailleurs....
Les quelques points que tu as soulevés sur le sql privé ont leurs importances..et perso ayant un 240 plan je ne suis pas sur de trouver mon compte avec les nouvelles formules....

Le 240Plan est un gros problème à transférer sur une nouvelle offre si tu utilisais la plupart des bases de données (15x45Mo) et/ou des comptes email (1000). Parce que l'offre Pro et l'offre Business ne proposent que 4 bases de données (plus grosses, mais 4) et que l'offre Pro n'a que 100 comptes email.

Donc si tu veux garder les 1000 email et avoir tes 15 bases de données de 50Mo, il faut par exemple prendre un Business et une option base de données supplémentaires OU un SQL Privé adapté à tes besoins (donc pas forcément un 128Mo RAM)

Par exemple :

Business : 9,99 euros/mois
20 bases de 50Mo : 12 euros/mois (Il n'est pas possible de prendre 10 bases ; on peut prendre 2x 5 bases mais cela revient au même prix que 20)
OU un SQL Privé : 6 euros/mois pour 128Mo RAM, 12 euros pour 256Mo, 20 euros pour 512Mo,...

Donc, par exemple :

9,99 + 12 = 21,99 euros/mois (Options 10 ou 20 bases supplémentaires)
OU
9,99 + 6 = 15,99 euros/mois (avec SQL Privé 128Mo RAM)
OU
OU 9,99 + 12 = 21,99 euros/mois (avec SQL Privé 256Mo RAM)

Là où c'est dur c'est que le 240Plan, c'était 7,77 euros/mois. D'où les difficultés sur cette offre. (Alors que pour un utilisateur d'un 300GP, les nouvelles offres sont tout bénéfice.)

Tu peux aussi partir sur une offre "Pro" moins chère et rajouter les options BDD ou SQL Privé ET une option email, mais tu arrives dans les mêmes eaux (Ce qui montre que les nouvelles offres sont cohérentes entre elles.)

Ohax a dit:
C'est une solution intéressante, mais j'attends les retours sur les performances et surtout les possibilités de sauvegarde.

Sinon... Le cpu... Il y a des limites ?

Puissance CPU toujours pas connue. Peut-être quelqu'un aura-t-il le temps de lancer un benchmark MySQL.

Pour les sauvegardes

http://forum.ovh.com/showpost.php?p=295474&postcount=137
...Les snapshots existent, mais ce sont des snapshots de tout le serveur. Actuellement ce n'est pas accessible sans passer par le support, mais c'est là en cas de besoin. On va ajouter la possibilité de lancer des sauvegardes de façon périodique dans le manager sur une ou plusieurs bases(un genre de cron)
Tony (OVH)

Pas assez de retours sur les performances et les sauvegardes actuellement pour que ce soit significatif.
On peut citer pour ce qu'ils valent uniquement quelques témoignages du fil http://forum.ovh.com/showthread.php?p=305640 (pour les performances, posts 54, 94, 115, 120 et autres, et des posts du 15 mai après le lancement SQL privé et 26 août 2006) mais cela reste PÖNCTUEL. A noter que Tony de OVH se donne beaucoup de mal dans ce fil, merci à lui.

Mêmes réserves importantesde lecture pour la question des sauvegardes en cas d'incident; même fil au 27 juillet 2009 , et au 19 août 2009 (Il semble toutefois que le loi de Murphy ait frappé ces jours-là)

nza2k · 27 Août 2009

Une reco pour adminblue.

Merci beaucoup pour ces explications claires et accessibles, tout en étant suffisamment détaillées.

nico78 · 27 Août 2009

adminblue a dit:
Si tu te servais de beaucoup de tes bases 720Plan et XXPlan, oui, la situation est assez compliquée.

c'est le cas ! :? De plus quand je vois les problémes sur le SQL privé, je me dis que je vais prolonger d'un an mes hébergements .....
....

adminblue a dit:
N'aurait-il pas été préférable d'utiliser une infrastructure Kimsufi + un backup pour base du SQL Privé?! (Le backup SQL Privé a déjà connu des ennuis exposés sur les forums OVH mais ils ont peut-être eu la poisse.)

Pour le Kimsufi, je ne sais pas le gérer, le mutualisé chez ovh, c'était le top avant, maintenant, c'est la galère rien que pour tout basculer sur un SQL Privé. (voir problème sur forum ovh)

Pour ma part, je compte remplacer mes 2 hébergements 720plan (17 ttc) et xxlplan (35ttc) avec un seul PRO (6e ttc)+ 2 sql privé 256 mo (pour séparer les bases importantes des bases secondaires) (12 ttc), normalement, cela va me revenir moins cher (30e ttc), donc ovh qui souhaite gagner plus, c'est pas encore çà

adminblue · 30 Août 2009

adminblue a dit:
seebz a dit:

mims1664 a dit:

Pensez vous qu'il soit possible d'héberger sa base de donnée sur un RPS et se connecter depuis un MUT dessus ?

Cliquez pour agrandir...

Je ne sais pas pour les RPS mais normalement, on ne peut pas accéder à un DB d'un dédié depuis un hébergement mutualisé. Je dit "normalement" car c'est ce qui semble être définit par OVH.

Dans les faits, c'est actuellement possible (j'ai encore testé il n'y a pas si longtemps que ça).. mais est-ce que ca va durer ?
Certaines personnes ont contourné le problème en utilisant un port différent.

Cliquez pour agrandir...

Seebz a raison. Normalement c'est non mais... il y a un truc (parfois cité par la hot line)... ne le dis pas trop fort STP parce qu'on voudrait bien le garder ! En fait, je crois que beaucoup de clients partiraient si le truc n'était plus possible.

A mon avis, la politique de connexions externes vers MySQL est assez antique chez OVH, voire peu compréhensible. On pourrait à la rigueur comprendre que l'on ne puisse pas se connecter directement depuis une machine extérieure vers un SQL mutualisé, mais depuis un serveur OVH sur le même réseau, c'est déjà plus contestable. Mais, surtout, cela fait des années que d'autres hébergeurs offrent la possibilité de connexions directes depuis l'extérieur avec, dans leur panneau de contôle, la sécurisation de cette connexion en filtrant par IP ou domaine, etc. (Planethoster, HostMonster, Servage,..), et en limitant les droits MySQL, et leurs réseaux ne sont pas des gouffres d'insécurité non plus.

Finalement, la réponse vient de tomber dans un fil sur le forum OVH. Connecter un dédié OVH à un mutualisé OVH pour faire du SQL sur le dédié, c'est Niet, au mieux c'est limité. http://forum.ovh.com/showthread.php?t=50679

Mais l'argument m'a scié, je dois dire. En fait, si j'ai bien saisi, la connexion mutu OVH vers dédiés OVH passe sur le réseau public. Donc OVH la limite ou la rend impossible selon les cas (voir le fil). Qui a dit routage intelligent ?

Contributeur Glouf > On ne peut pas avoir des sites sur du mutu et ses bases de données
> mysql ailleurs (dédié ovh ou ailleurs) ?

Réponse Octave, directeur OVH: non. et ça date qu'il y a 10ans.

Contributeur Glouf > Pour moi le serveur Kimsufi n'est pas une "connexion à un réseau extérieur". Si OVH décide que je n'ai pas le droit
> d'héberger mes bases SQL sur un Kimsufi c'est son droit, mais qu'on ne m'accuse pas de n'importe quoi,
> je n'ai pas de serveur ailleurs.
> Si un phpBB3 avec une vingtaine de personnes connectée (aucun bot car auth obligatoire) mérite ce genre
> de réflexion ou alors je pourrais dire que cela en dit long sur la qualité du réseau OVH...

(> ...)Quelle différence entre se connecter à serveur SQL hébergé sur un Kimsufi qui est donc bridée et se connecter à un SQLPRivé qui ne l'est pas ?

Réponse Octave, directeur OVH: le mutu est derriere de firewall. tout ce qui se passe derrier le firewall
est derriere le firewall. et si vous vous connectez sur une IP public la connexion sort du reseau privé vers le reseau public. ça prend des resources et on le limite.

Et à la question de bon sens

Contributeur Glouf > Ok. Une idée à creuser serait peut-être de pouvoir avoir des dédiés en IP privée.

La réponse est

Réponse Octave, directeur OVH: sql privé.

Voir plus haut dans ce fil la comparaison des prix entre vrais dédiés avec 2 à 4Go de RAM et SQL Privé sur VPS avec 512Mo ou 1 Go...

adminblue · 5 Septembre 2009

Les réalités techniques semblent refaire surface chez OVH concernant les 128Mo de RAM de leur SQL Privé standard (qui n'a rien de criticable en tant que tel) et les limites de celui-ci, comme on le disait depuis un moment.

Octave directeur OVH (répondant à un client qui se plaint de problèmes sur un SQL Privé de 128MO de RAM ; vous avez l'URL pour lire le post et tout le thread)
La base a une taille de 443Mo. ça fait un peu beaucoup pour 128Mo de RAM

http://forum.ovh.com/showpost.php?p=307181&postcount=239

En fait, le client indique que sa base ne ferait que 220Mo (?)

Membre forum OVH
En fait c'est 220Mo (d'apres phpmyadmin)
J'accepte qd meme le principe que c'est(220Mo) beaucoup pour du 128Mo.

http://forum.ovh.com/showpost.php?p=307183&postcount=240

Donc, aujourd'hui, le bon sens a prévalu et OVH indique avec justesse que
"La base a une taille de 443Mo. ça fait un peu beaucoup pour 128Mo de RAM."

Ben oui, c'est évident pour un administrateur MySQL...

Mais c'est quand même à rapprocher du discours officiel d'il y a trois semaines :

Octave Directeur OVH
ah bahh parfait ! 40 bases de 20Mo c'est que dale pour un sql privé de 128RAM.

http://forum.ovh.com/showpost.php?p=301401&postcount=188

Alors, certes, une grosse base unique est généralement plus difficile à gérer pour un serveur que plusieurs petites bases d'un encombrement total égal à celui de la grosse base, mais, dans ce cas, on parlait de... 800Mo (20x40) pour 128Mo de RAM et on disait que c'était "que dalle" !

Trois semaines après, "443Mo. ça fait un peu beaucoup pour 128Mo de RAM".

Allez, encore un effort, et OVH en reviendra à ce qu'il disait très justement il y a des mois, avant de lancer le SQL Privé :

Octave Directeur OVH
si tu veux une base rapide, ta base est dans la ram. c'est un simple fait d'admin sql. sinon c'est lent.

http://forum.ovh.com/showpost.php?p=235388&postcount=28

Il faut aussi rappeler que OVH propose 4 bases de données (plus grosses) et un SQL Privé de 128Mo de RAM dans son offre Premium, qui est sensée (plus ou moins) remplacer une offre comme le XXPlan qui comportait 50 bases de 50Mo avec 50 connexions simultanées par bases.

Mais les réalités techniques se rappellent toujours à nous tôt ou tard...

HerVil · 20 Octobre 2009

Bonjour,
Question pour les administrateurs de site sous Drupal 6 :
Est-ce que selon vous, cette offre OVH est une bonne réponse par rapport à la limite pratique observée lorsqu'on administre un site sous Drupal, à savoir la valeur par défaut de la RAM à 32Mo que l'on "tape" à peu près systématiquement ?
Merci

adminblue · 20 Octobre 2009

HerVil a dit:
Est-ce que selon vous, cette offre OVH est une bonne réponse par rapport à la limite pratique observée lorsqu'on administre un site sous Drupal, à savoir la valeur par défaut de la RAM à 32Mo que l'on "tape" à peu près systématiquement ?
Merci

Les 32 Mo dont tu parles sont ceux alloués à l'exécution d'un script PHP. Donc, rien à voir avec la RAM d'un "SQL privé" qui s'occupe de SQL seulement. Ton PHP est toujours sur ton mutualisé OVH et toujours limité chez OVH à 32Mo, ce qui est une toutefois bonne valeur en mutualisé même si elle ne suffit pas dans certains cas.

Donc, pour répondre à ta question : NON, c'est autre chose.

SpeedAirMan · 20 Octobre 2009

HerVil a dit:
Bonjour,
Question pour les administrateurs de site sous Drupal 6 :
Est-ce que selon vous, cette offre OVH est une bonne réponse par rapport à la limite pratique observée lorsqu'on administre un site sous Drupal, à savoir la valeur par défaut de la RAM à 32Mo que l'on "tape" à peu près systématiquement ?
Merci

Infomaniak a une limite plus intéressante : 64Mb (voir le sujet où j'en parle : Hébergement web Infomaniak : nouveautés et évolutions)

Nouveauté de septembre (je cite) : "La mémoire allouée pour vos scripts passe de 48 à 64 Mb"

easy_zik · 26 Novembre 2009

Bonjour,

Je remonte un peu le sujet pour vous expliquer mon problème : Je suis chez OVH depuis un moment, et j'avais jusqu'à présent un 90 Plan qui me satisfaisait bien... sauf au niveau de la taille de la base de données qui commençait à devenir un peu "limite".

Je me suis donc dit : "passons on l'offre mutu PRO" !

El la horreur.... :evil:

Je suis passé de 5 bases à 4 bases, donc j'ai fusionné 2 bases en 1 pour arriver à une base totale de 80Mo environ (on à droit à 500 Mo pour la plus grosse)
Mais les perfs ne sont pas du tout au rendez-vous, et j'ai constamment des messages d'erreurs qui me disent que je dépasse le nombre de connexions simultanées !! (Je ne vois pas l'interet dans ce cas d'autoriser des bases de 500Mo si on ne doit pas lire les données qu'il y a dedans mais bon...)

Bref, je suis exaspéré aujourd'hui, et bien sûr OVH dit que tout est OK de son coté... J'envisage donc de prendre un Sql Privé, mais je voulais savoir combien de temps ça va me suffire ? Car si on considère qu'à partir de 128 Mo, ma base va ramer (taille de la RAM), ça va pas durer très longtemps...
Et c'est quand même 6Euro HT de plus, donc ça fait plus que doubler le prix de mon hébergement.

Je me demandais ce que pouvais donner en performance un RPS I à la place d'un Sql Privé + Hebergement Pro mais je suis pas sûr que ce soit beaucoup mieux même avec 512 de RAM, sachant que je perds en plus en espace disque et bande passante...

Bref, je suis un peu embêté, j'ai pas assez d'argent pour un kimsuffi, et j'aurais donc besoin de vos conseils avisés :wink:

fredou · 21 Août 2013

SQL Privé d'OVH

Moi je vous déconseille fortement !!!
J'ai installé 1 base de données de 50 MO qui n'est même utilisée sur un site, et on trouve le moyen de me dire :

"Le serveur a dépassé la quantité de mémoire physique qui lui est alouée, pouvant entraîner une perte de performance de celui-ci. Nous vous conseillons de passer à une offre supérieure."

Bah tiens, évidemment ! Comment c'est possible, la bdd n'est pas utilisée sur le moindre site !!!!

Après je créé une 2ème bdd, importe un fichier SQL et là le plantage :

"Etat : Opération en cours sur le serveur...
Statut : Un problème est apparu, nous y remédions..."

Ca fait des heures et des heures que l'opération est en cours et que soi-disant ils y remèdent, et en attendant je fais quoi moi ??? Ca va revenir un jour ou quoi ???

Bref, je ne peux que conseiller d'aller voir ailleurs d'autant plus que j'ai aussi des problèmes de disponibilité avec l'hébergement mutualisé, c'est bien trop souvent que mon site affiche des erreurs 500 / 502 parce que selon le support technique il y a des "pics d'activité" à certaines heures (sur d'autres sites que le mien je précise, c'est un hébergement mutualisé). Ca a le mérite d'être franc mais vraiment je rêve...

J'en profite donc pour demander si vous connaissez un hébergeur plus sérieux ?

Leonick · 21 Août 2013

pourquoi prendre un sql privé pour une aussi petite bdd ?
pourquoi ne pas prendre un kimsuffi ou autre dédié d'entrée de gamme ?