RPS III vs KIMSUFI

Audiofeeline · 7 Février 2010

Salut tout le monde,
je commence à être un peu juste sur mon Kimsufi 500G niveau puissance, est-ce que le RPS III serait plus costaud et supporterait mieux les montées en charge ou faut-il directement passer au RPS IV ?
Merci de vos réponses...

Julia41 · 7 Février 2010

Même le RPS IV serait moins costaud que ton kim. Le disque réseau est le plus mauvais point niveau performance.
Si tu n'as aucun accès disque, ça peut être valable, sinon ce n'est pas la peine.

Tu pourrais regarder aussi pour optimiser un peu ta configuration : qu'est-ce qui te fait penser que ton kim est "un peu juste" ?

petitchevalroux · 7 Février 2010

Tout dépends de ce que tu veux dire par "un peu juste". Le problème des RPS c'est que les accès disques sont plutôt lent donc pour héberger un MySQL chargé c'est limite. Personnellement j'utilise un RPS I et je trouve que les accès disques sont hyper lent lors de mes synchro unison ou lors de déplacement de gros fichier.

Aprés pour mes besoins (moins de 5000pv/j) le RPS est tout simplement la meilleure offre du marché et me permet d'avoir le confort d'utilisation d'un dédié sans en payer le prix. J'ai juste adapter mon CMS au RPS en cachant en RAM mes pages (donc plus d'accés disque pour l'affichage) et la réactivité de mes sites est plutôt bonne.

Voici quelques liens qui peuvent t'aider dans ton choix :
Benchmark disque rps kimsufi gandi
Benchmark mysql rps kimsufi gandi

Personnellement je n'utiliserai pas un RPS en tant que évolution d'un kimsufi mais cela n'engage que moi :mrgreen:.

Audiofeeline · 7 Février 2010

Julia41 a dit:
qu'est-ce qui te fait penser que ton kim est "un peu juste" ?

En cas de "buzz" le serveur plante, le CPU est au taquet, selon moi il est un trop juste. Mon site (principalement mon WWW) est relativement bien optimisé et mis en cache (2h). Trop de connexions simultanées et ça crashe en gros. Les RPS seraient moins performant que le Kimsufi selon vous?

L'avantage du RPS c'est son double cœur je pense, non?

Duffy · 7 Février 2010

Le problème du RPS c'est que pour accéder au disque tu passes par le réseaux et donc en cas de coupure du filer ton site ne marche plus alors que sur un dédié ça ne peut pas arriver (sauf si le HDD meurt

) m'enfin passons.

De plus si ton serveur a déjà du mal, je n'ose imaginer le résultat sur un RPS car les appels à la bases seront encore plus lents je pense, à ta place je prendrais plutôt un KS 750G si tu en as les moyens, sinon as-tu vérifier tes paramêtres de bases de données pour voir si tu ne peux pas les optimiser ? Il y a tunner-primer.sh qui existe pour MySQL (je suis pas sur du nom, mais c'est un truc qui y ressemble

) qui pourrait te donner des pistes d'optimisation.

Audiofeeline · 7 Février 2010

Le problème ce sont les forts pics d'audience... Je vais surement migrer vers le 750G, il faut se donner les moyens d'avoir les moyens!

salva · 7 Février 2010

Audiofeeline a dit:
Trop de connexions simultanées

C'est à dire ?

Audiofeeline · 7 Février 2010

Trop de monde d'un coup...

salva · 7 Février 2010

Oui j'avais compris

Le nombre en simultané si ce n'est pas top secret.

Audiofeeline · 7 Février 2010

J'ai pas réussi à chiffrer puisque c'est tombé à chaque fois, mais j'imagine que ce doit être de l'ordre de la centaine à la minute... :/

tyv · 7 Février 2010

Audiofeeline a dit:
Le problème ce sont les forts pics d'audience... Je vais surement migrer vers le 750G, il faut se donner les moyens d'avoir les moyens!

pour le même prix, il y a le sp mini avec comme avantage deux disques en raid (pour un serveur c'est quasiment obligatoire) et des garanties d'interventions supérieures (déjà testé avec succés lors d'un changement d'alimentation

).

Julia41 · 7 Février 2010

As-tu fais toutes les optimisations possibles niveau Apache / MySQL ?
As-tu pensé à tester d'autres serveurs web ? (Propagande de ma part mais Lighttpd est beaucoup plus performant).

Edit: je viens de voir que tu étais sur WP, tu pourrais tenter le module de cache "memcache<je ne me rappelle plus>".
Beaucoup plus performant.

Sinon, tu peux déjà optimiser ton serveur SQL (si ce n'est pas fait) par :

Code:

cd /etc/mysql/
wget http://www.day32.com/MySQL/tuning-primer.sh
chmod a+x tuning-primer.sh
./tuning-primer.sh

Tu aurais déjà pas mal d'idées sur ce qui va pas si ce n'est pas encore fait.

Audiofeeline · 8 Février 2010

Merci de l'info mais je pense que c'est le Kimsufi qui ne tient tout simplement pas la charge. Une fois en cache, il n'y a plus aucun accès à SQL donc normalement ce ne sont pas les requêtes qui plombent la machine mais plutôt la surcharge, non?

salva · 8 Février 2010

Je te recommande aussi tuning-primer

Si tu n'as pas optimisé le serveur tu ne peux pas avancer qu'il ne tient pas la charge.

Ton cache mysql est-il bien activé ? Par défaut sur les kimsufis en release2, ce n'est pas le cas.

Il n'y a pas photo entre serveur installé brut de décoffrage et un autre optimisé.

tofm2 · 8 Février 2010

Julia41 a dit:
As-tu fais toutes les optimisations possibles niveau Apache / MySQL ?
As-tu pensé à tester d'autres serveurs web ? (Propagande de ma part mais Lighttpd est beaucoup plus performant).

Edit: je viens de voir que tu étais sur WP, tu pourrais tenter le module de cache "memcache<je ne me rappelle plus>".
Beaucoup plus performant.

Sinon, tu peux déjà optimiser ton serveur SQL (si ce n'est pas fait) par :

Code:

cd /etc/mysql/ wget http://www.day32.com/MySQL/tuning-primer.sh chmod a+x tuning-primer.sh ./tuning-primer.sh

Tu aurais déjà pas mal d'idées sur ce qui va pas si ce n'est pas encore fait.

merci pour l'info, je ne connaissais pas

tofm2 · 8 Février 2010

Comme d'habitude dans ce genre de situation, je recommande d'abord de dissocier le serveur web du serveur MySQL, Il est en effet beaucoup plus rentable et certainement moins cher d'avoir deux petits serveurs que un gros, donc trè cher qui finira toujours par se mélanger les pinceaux en cas de pic de fréquentations.

Dans ton cas, regarde, tu as déjà un Kimsufi 500G à 29, 99 € / mois, si tu veux la gamme au dessus, ça te coutera 49 € mois, et si ton site poursuit sa croissance, dans deux mois, il te faudra le top des kimsufi à 99 € / mois, et ainsi de suite. Dans ce cas, c'est toujours le serveur MySQL qui est le facteur limitant (toujours plus demandeur en ressources que le serveur web)

Mon conseil,

1) tu gardes ton kimsufi et tu lui réserves uniquement le serveur MySQL
2) tu souscris un RPS I et tu y transfères uniquement ton serveur web

La facture se montera au total à environ 40 €/mois pour un paiement à l'année, beaucoup plus avantageux que de passer directement à un kimsufi 750G à 49,98 €/mois (10 € / mois d'économie, soit 140€/an)

à mon avis , comme cela tu seras tranquille plus longtemps, et tu feras évoluer tes deux serveurs à la demande de façon beaucoup plus économique. Si ton RPS ne sert qu'au serveur web, tu auras vraiment de la marge avant de le faire saturer.

à étudier

Julia41 · 8 Février 2010

Audiofeeline a dit:
Merci de l'info mais je pense que c'est le Kimsufi qui ne tient tout simplement pas la charge. Une fois en cache, il n'y a plus aucun accès à SQL donc normalement ce ne sont pas les requêtes qui plombent la machine mais plutôt la surcharge, non?

Le problème peut alors venir d'ailleurs. Généralement en cas de plantage, Linux est quand même bavard. Tu as toujours des requêtes SQL même lorsque ton site est en cache normalement, peut-être qu'un de tes plugins fait une boucle de porc et alors ça revient à un crash.

Sinon, au niveau de la release 2, en 64 bits, plusieurs personnes reportent des crashs au niveau de MySQL.

Au niveau du crash, si le dédié est encore accessible en SSH, c'est à ce moment là que tu devrais regarder.

La solution de toujours dire "mon dédié est pas assez puissant" n'est pas toujours la bonne et ne fait que reporter le problème (ma voiture ne va pas assez vite, mince, je pensais qu'une fois en première, il ne fallait pas toucher le levier de vitesse).

En tout cas, s'il plante vraiment (crash), le problème ne vient pas du dédié, qui bien configuré serait sensé dégager les nouveaux visiteurs ou les ignorer mais à la rigueur être "lent". S'il plante complètement le problème vient d'ailleurs.

Audiofeeline · 8 Février 2010

J'ai comme l'impression qu'on essaye de me vendre de l'infogérance là... :roll:

tofm2 · 8 Février 2010

Audiofeeline a dit:
J'ai comme l'impression qu'on essaye de me vendre de l'infogérance là... :roll:

et pourquoi pas ; mais moi, je n'ai rien à te vendre..

@audiofeedline, les vidéos de ton site (youtube et dailymotion) ne se lancent pas de chez moi.

Julia41 · 8 Février 2010

Il ne faut pas voir le mal partout

Je te donne des pistes, et Google fait de l'infogérance gratuite.

Sinon, concernant le début de ton post, j'ai déjà donné mon avis sur le RPS par rapport au Kim, si vraiment tu dois changer de serveur, passe sur un SP (les SSD sont vraiment performant) Mini par exemple.

tofm2 · 8 Février 2010

Julia41 a dit:
Il ne faut pas voir le mal partout
Je te donne des pistes, et Google fait de l'infogérance gratuite.

du mal ? maisje ne vois de mal nulle part là dedans. :wink:

Audiofeeline · 8 Février 2010

Non vraiment, j'ai beau retourner le problème dans tous les sens, je ne vois pas ce qui peut faire planter le serveur, j'ai déjà sur-optimisé mon blog, même la CSS fait quelques ko... MySQL est très peu sollicité et ne plante pas chez moi.

Je pense vraiment que c'est une histoire de CPU qui n'arrive pas à encaisser les montées en charge.

tofm2 · 8 Février 2010

souvent le nombre de processus engendrés par mysql et ceux de apache font que la CPU fait une dépression nerveuse, même des processeurs puissants. Essaye de déporter la BDD sur un serveur qui lui est propre. Juste pour voir.

C'est pour ton blog en www? personnellement, je trouve que ça tourne plutôt bien (sauf que les vidéos refusent de se lancer chez moi, mais les vidéos, c'est pas toi, c'est youtube ou dailymotion.

Julia41 · 8 Février 2010

@Audiofeeline, quand ta machine plante, c'est la machine "entière" ? (Obligé de faire un reboot hard ?) ou juste un truc à relancer ?
Si tu as l'heure "a peu prêt exacte" du plantage, fouine dans ton /var/log/kern.log voir syslog.
Tu devrais avoir des infos sur le plantage dans ces deux logs, pareil dans les logs d'erreur apache.