OVH Community, votre nouvel espace communautaire.

Surcharge du VPS dûe à un seul site (cms)


roadster
13/03/2014, 16h11
Citation Envoyé par Isendel
Pour le moment j'ai migré tous mes clients dans ce cas de figure sur un dédié et idem tout roule là-bas....
Je crois que c'est la seule solution envisageable à court terme, j'ai un SP 16G qui fera très bien l'affaire, mon client ne se satisfera pas d'une promesse sur les VPS 2014

Je vais continuer à insister auprès du support pour tenter d'avoir une explication, mais quoi qu'il en soit, je ne recommanderais plus un VPS OVH pour des sites de production.

Isendel
13/03/2014, 15h57
Je suis preneur de tes retours roadster et ça me remonte le moral de voir que je ne suis pas le seul (youpi je n'hallucine pas).

Je pense qu'il y a soit une subtilité au niveau de la config du VPS mais alors là ça m'échappe car j'ai cherché un peu partout déjà. Autrement un soucis au niveau des VPS eux-même mais c'est bizarre car les VPS avec presta ou d'autres CMS préinstallés fonctionnent bien je pense sinon ça se saurait...

Pour le moment j'ai migré tous mes clients dans ce cas de figure sur un dédié et idem tout roule là-bas....

lanac
13/03/2014, 14h50
Il ne vaut mieux pas migrer vers InnoDB sachant que MyISAM est le champion en terme d'écriture car il ne doit pas gérer l'intégrité des données...
Du coup à mon avis, je pense que le mieux à faire est d'attendre la migration des VPS vers la version 2014 en espérant que ça ne soit plus très long depuis le temps qu'on nous le promet...

roadster
13/03/2014, 14h27
Je suis au courant des piètres performances des accès disque sur les VPS. Ceci dit, dans le cas présent, les accès mySQL sont essentiellement en écriture, de plus à travers memcache, ce qui les réduit encore.

La majorité des tables de Prestashop dans ma base sont en MyISAM. Je pourrais les passer en InnoDb, et migrer la base sur MariaDB (je sais, c'est binairement compatible, et tout ça), mais :

1) d'une part, je ne suis pas sûr de l'impact dans Prestashop (surtout MyIsam -> InnoDb)
2) d'autre part, les performances étaient acceptables il y a encore quelques temps, donc je ne suis pas sûr que migrer règlera le problème.

En un mot comme en cent, ça marchait bien, maintenant ça marche très mal, et on n'a rien touché.

WTF, j'ai envie de dire ;-)

lanac
13/03/2014, 14h18
Bonjour,
J'ai eu ce genre de soucis avec un service qui fait beaucoup d'écriture en DB. J'utilise InnoDB pour cela, qui de base n'est pas très bien optimisé pour les écritures intensives.
Il y a plusieurs solutions pour régler ça :
1°) passer à MariaDB
2°) ajouter les options suivantes dans ton my.cnf :
innodb_old_blocks_time = 1000
innodb_stats_on_metadata = Off
innodb_file_per_table
innodb_log_file_size = 100M
innodb_flush_method = O_DIRECT
innodb_flush_log_at_trx_commit = 0
Je te laisse regarder la doc au sujet de ces options mais il faut savoir qu'une série d'entre elles viennent directement de la config de base de MariaDB ou MySQL 5.6 où un véritable travail de réflexion et optimisation a été fait au niveau du moteur InnoDB.
Les VPS actuels sont très mauvais en écritures et temps d'accès disque, ce n'est un secret pour personne... Du coup les moindres optimisations à ce niveau se font fortement ressentir

J'espère que ça te permettra de solutionner ton problème...

roadster
13/03/2014, 13h53
Je fais remonter le sujet à mon tour, pour des lenteurs insupportables et inexpliquées de mon VPS. C'est un VPS cloud2 sous Debian 6, une installation traditionnelle aux petits oignons, avec ISPConfig 3, que je trouve bien pratique.. J'ai dessus une unique boutique PrestaShop, qui a très bien fonctionné dans les premiers temps.

Actuellement, les temps de réponse sont exécrables, et 5 requêtes concurrentes suffisent à écrouler la machine, les 2 vCore à 100% pendant plusieurs minutes. OK, Prestashop n'est pas un modèle de sobriété, mais quand même.
Tout est normal dans mes logs et dans Munin, et hors PHP, la machine se tourne tranquillement les pouces.

Voilà ce que ça donne avec 5 clients concurrents qui font chacun séquentiellement 100 requêtes (simulés avec jMeter). 5 clients, c'est pas grand chose...



Les temps de réponses: entre 5 et 8 secondes !





Je n'ai pas de snapshot qui renlentirai la machine, et j'ai bien EnableSendfile à Off dans la config d'Apache, et tout devrait rouler.

Du coup, j'ai copié la boutique complète sur un dédié OVH qui a exactement la même config logicielle, sur laquelle tourne une dizaines de sites et applis web,et qui elle aussi se tourne tranquillement les pouces la plupart du temps.

Et là, tout marche très bien, avec des temps de réponse excellents::



Les temps de réponse en millisecondes (toujours 5 clients concurrents qui font chacun 100 requêtes)



OK, il y a 4 vrais cores sur le dédié, mais je ne m'explique pas une telle différence de performances.

Je vais ouvrir un incident, mais en attendant, quelqu'un aurait une piste ?

Isendel
21/02/2014, 08h54
Je reviens un peu à la charge mais personne n'a d'idée ?
Peut-être que cela n'est pas spécifique aux VPS et que je devrai plutôt poster dans une rubrique plus générale.

En tous cas sur nos dédiés nous n'avons pas ce problème.

Isendel
12/02/2014, 08h41
Salut et merci de ton intervention,

Qu'appelles-tu les slides ? Je ne vois pas ce que c'est.

Merci.

microfacile73
12/02/2014, 07h01
bonjour

regarde les slides ?

j' avais deja eu ce probleme au par avant ...

Isendel
11/02/2014, 13h56
Amis du jour bonjour,

J'ai plusieurs sites paramétrés sur un VPS et tout va pour le mieux dans le meilleur des mondes. Je n'utilise pas de CMS pour développer mes sites.
Dernièrement j'ai eu deux mésaventures, la première en hébergeant le site d'un client en Wordpress, la seconde un site en Joomla.
Le serveur surcharge à 200% (les deux coeurs à 100%) et le htop me montre que c'est le site en question qui lance des processus en boucle et bouffe toutes les ressources (après le proc c'est la mémoire qui monte à 100% assez vite).
On dirait qu'il n'arrive pas à faire ses calculs et que tu fout le camp en conséquence.

Quand le site en Joomla a planté, j'ai pris le temps de faire quelques tests par défaut mon environnement n'utilisait pas fast-cgi :
[Mon Feb 03 19:34:10 2014] [error] [client xxx.xxx.xxx.xxx] Script timed out before returning headers:

J'ai ensuite activé fast-cgi car par le passé cela m'avait déjà sauvé la mise, résultat en warning avant chaque erreur mais pas mieux :
[Mon Feb 03 19:52:33 2014] [warn] [client xxx.xxx.xxx.xxx] Timeout waiting for output from CGI script
[Mon Feb 03 19:51:33 2014] [error] [client xxx.xxx.xxx.xxx] Script timed out before returning headers:

Pour ces erreurs rien d'anormal semble-t-il dans les logs d'accès :
xxx.xxx.xxx.xxx - - [03/Feb/2014:19:32:09 +0100] "GET / HTTP/1.1" 200 6747 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)"

Voici le htop pour la version avec fast-cgi d'activée, à noter que ça faisait pareil sans le fast-cgi :


Une idée ?