Aide choix VPS net4all / RPS / DEDIE - OVH

[tomlelab]

Bonjour

mon site est actuellement hébergé chez net4all.ch sur un VPS pour 980 euros par an.

Le site sature en mémoire vive régulièrement (1 fois par semaine) et donc le serveur devient inaccessible (pas cool).

Je souhaite donc changer et j'aurais aimé avoir vos avis et comprendre les différence entre 2 offres chez ovh avec des machines qui semblent plus performantes et néanmoins moins cher que mon hébergement actuel.

Mon site consomme surtout de la mémoire vive: c'est la bdd qui est gourmante, elle fait 130 mo, et il y a énormément de routines php et d'accès à la bdd. Je n'ai pas besoin d'un gros disque dur.

Ma config actuelle est le vps4 chez net4all: http://www.net4all.ch/hebergement/serveur-virtuel/

pour résumer: 1 go de mo / 24 go de disque dur pour 90 euros par mois

J'hésite entre:

Le RPS5 d'ovh à 47 euros par mois

http://www.ovh.com/fr/produits/rps5.xml

4 GO de mémoire vive

et le dédié superplan bestof à 82 euros par mois.

http://www.ovh.com/fr/produits/superplan_best_of.xml

4GO de mémoire vive

Ma question est: y-a-t-il des mauvaises surprises, sur ces configurations ? pourquoi est ce moins cher et/ou plus performant sur papier ?

Merci de votre aide.

Modifié 10 Août 2009 par tomlelab

[Jeanluc]

La gamme RPS d'OVH ne sera plus disponible après le 14 septembre. D'après les annonces faites par OVH sur son forum, cette gamme sera remplacée par des "RPS infogérés" (donc sans accès root pour le client) et par des serveurs dédiés plus classiques. Les contrats RPS existants continueront, bien entendu, après le 14 septembre.

Jean-Luc

[interzine]

Ton site ou ton réseau, sa comporte combien de visites et de trafic pour avoir besoin d'un tel dédié ? Pourquoi ne pas t'offrir un simple hébergement illimité à moins de 50€ par an !?

[tomlelab]

Ton site ou ton réseau, sa comporte combien de visites et de trafic pour avoir besoin d'un tel dédié ? Pourquoi ne pas t'offrir un simple hébergement illimité à moins de 50€ par an !?

Déjà essayé mais ça ramait ou dépassait les limites autorisées en mutualisées (taille de bdd ou nb de connexions simultanées).

[mtcocktail]

Déjà entre les deux je te conseil vivement le serveur dédié superplan. Les RPS ont déjà fait preuve de quelque pannes et il ne sont pas là pour recevoir des applications en production mais plus pour avoir des plateforme de test moins cher.

Ensuite la différence de prix entre net4all et ovh est une différence logique entre un hébergeur dis Professionnel et un hébergeur de masse comme ovh. Par contre tu n'auras peut-être pas les même services. Net4all est également une société de service, elle pourra donc te répondre plus aisément au téléphone, te conseiller, te vendre des solutions et du services informatique. Ovh eu ne te vendront que de l'hebergement. A toi d'être compétent pour la gestion et l'administration de tes applicatifs.

[Kioob]

A ce titre d'ailleurs ton hébergeur actuel peut peut-être diagnostiquer un problème dans ta configuration, qui t'éviterait un changement de serveur.

En effet si cette consommation mémoire n'est pas justifiée, le problème peut rester présent avec une machine équipée de 2, 4 ou 8Go de RAM. As tu cherché à connaître l'origine de ce problème ?

[tomlelab]

J'ai des scripts très gourmands, beaucoup d'accès disques (si j'ai bien compris à cause de requêtes très volumineuses), on a essayé plusieurs config sur le vps mais sans succès. Je pourrais revoir l'architecture de ma bdd, pour gagner un peu, mais je pense que l'application veut ça.

[Kioob]

C'est possible oui, la question était surtout de savoir si cela avait été fait ou non ; même si pour ma part une telle consommation mémoire pour une base aussi petite me surprend un peu.

[Dan]

Une petite base peut être très gourmande en ressources. Il faut absolument tracer les "slow queries" et corriger celles qui bouffent trop de ressources.

L'un de mes contacts a une appli développée par une société dont je tairai le nom, mais dont la moindre requête contient au moins 6 ou 7 JOIN (avec en plus des LIKE '%mot_cle%') , ce qui lui vaut des requêtes qui durent jusqu'à plusieurs dizaines de secondes pour ressortir un seul élément.

Seul le fichier des "slow queries" a permis de tracer ces requêtes "ogresques".

[tomlelab]

Seul le fichier des "slow queries" a permis de tracer ces requêtes "ogresques".

Ou est ce qu'on trouve le fichier des slow queries ?

[Kioob]

Il faut regarder ça dans la conf MySQL (dossier /etc/mysql et /etc/mysql/conf.d/ sous Debian).

Il s'agit d'entrées de ce genre :

log_slow_queries	   = /var/log/mysql/mysql-slow.log
long_query_time = 1

Voir également (pour détecter de potentielles autres erreurs) :

log-queries-not-using-indexes

La première indique le chemin où sera stocké le fichier de log en question, la deuxième indique la durée (en seconde) à partir de laquelle une requête est jugée lente, et la dernière comme son nom l'indique trace toutes les requêtes n'utilisant pas d'index (ce qui peut être une erreur... ou pas).

[tomlelab]

Il faut regarder ça dans la conf MySQL (dossier /etc/mysql et /etc/mysql/conf.d/ sous Debian).

Merci, je n'ai pas trouvé cette ligne dans le fichier, mais je crois que le log n'est pas activé.

Est ce qu'en rajoutant cette ligne, ça l'activera ou il faut activer le log ailleurs également ?

[Kioob]

Il faut ajouter les lignes en question, et relancer MySQL (ou bien modifier ces paramètres à chaud, bien que je ne sois pas certain que ce soit faisable pour log_slow_queries).

Tu peux toujours essayer depuis le client MYSQL :

set global log_slow_queries := /var/log/mysql/mysql-slow.log;
set global long_query_time := 1;
set global log_queries_not_using_indexes := 1;

[tomlelab]

Super, merci !