Gandi.net Groups

Bonjour, j'ai fait un rapide bench comparatif entre 1 part et ma machine
(ATHLON XP 2400+, pas tout jeune) et je trouve un rapport de 7,7. Ce qui
n'est pas flatteur ...
Ca correspond à un Celeron 400Mhz (peut etre moins). Quelqu'un peut il
confirmer mon évaluation car il serait bon de connaitre exactement ce
que vaut 1 part ( 1/3 de Pentium 4 selon le tableau ??, un petit P4
alors !)

Le 16 jan 2008 à 23:01 CET, macgiver a écrit :

Bonjour, j'ai fait un rapide bench comparatif entre 1 part et ma
machine
(ATHLON XP 2400+, pas tout jeune) et je trouve un rapport de 7,7. Ce
qui
n'est pas flatteur ...
Ca correspond à un Celeron 400Mhz (peut etre moins). Quelqu'un peut
il
confirmer mon évaluation car il serait bon de connaitre exactement ce
que vaut 1 part ( 1/3 de Pentium 4 selon le tableau ??, un petit P4
alors !)

Mes benchs me donne l'impression que Gandi a configuré Xen (au moins
pour la beta) pour qu'on ne puisse pas profiter du fait que le reste de
la machine ne fait rien pour avoir un ou plusieurs processeurs à soi
(par exemple une compilation noyau sur un ou deux processeurs avec 4
parts prend quasiment le même temps, ce qui semble indiquer que la
puissance totale est bridée).

C'est décevant car une part vaut alors 1/8ème d'un Opteron monocore à
2,6GHz. Ca donne un opteron à 325MHz sur lequel il faut compter
l'overhead de Xen donc le Celeron 400MHz ne doit effectivement pas
être très loin.

Ceci dit, il est possible que tu puisses bien mieux profiter du
sous-système disque des machines. Aux dernières nouvelles Xen ne
permettait pas de brider les I/O (et ça m'étonnerait que ça ait
changé, ce n'est pas une problématique triviale) et de toute façon
Gnadi ne le fait pas (j'ai mesuré 60Mo/s avec un test basique). Donc
si tes applications ont plus besoin de bande passante disque que de
CPU, il est possible que tu dépasses largement les capacités d'un PC
classique (qui peut atteindre 60Mo/s, mais qui n'a probablement pas des
disques SAS à faible temps de latence...).

J'espère qu'ils comptent enlever le bridage, parce que sinon même à
5€ la part ce n'est pas intéressant pour nous. Un des intérêts de
la virtualisation est que chaque machine profite du fait que toutes les
machines ne travaillent pas en même temps pour récupérer de la perf
qu'elle ne pourrait pas avoir sur un matériel dédié acquis au même
coût (énergétique, pécunier, espace, ...).

Lionel

Le 16 jan 2008 à 23:40 CET, Lionel Bouton a écrit :

Le 16 jan 2008 à 23:01 CET, macgiver a écrit :
la machine ne fait rien pour avoir un ou plusieurs processeurs à soi
(par exemple une compilation noyau sur un ou deux processeurs avec 4
parts prend quasiment le même temps, ce qui semble indiquer que la
puissance totale est bridée).


Lionel

Si le compilateur n'est pas multithread, le temps de compilation ne
varie guère quel que soit le nombre de processeurs.
Le bon test consiste à comparer le temps de 2 compilations successives
(avec un make  clean entre les 2) à deux compilations simultanées ( 2
repertoires noyaux) chacune dans une console.

Plutot que de tirer sur la memoire, le cpu et le disque en meme temps
avec une compile noyau, il est plus simple dans un premier temps
d'executer des boucles (quoique le cache processeur sera suffisant)




Eric

Si le compilateur n'est pas multithread, le temps de compilation ne
varie guère quel que soit le nombre de processeurs.

Que nenni ! C'est pas à un vieux singe qu'on apprend à faire des
grimaces non plus (cf grep -i 'lionel bouton'
/usr/src/linux/MAINTAINERS).

J'ai compilé le kernel avec make puis make -j2 pour comparer, ce qui
est le standard pour profiter de la présence de plusieurs CPU avec
make.

Si tu n'as jamais essayé de compiler un noyau comme ça sur une machine
SMP, il est temps d'essayer ! Sur une machine "normale" (i.e. non
bridée) le temps de compilation est quasiment divisé par le nombre de
processeurs (la compilation du noyau est extrèmement parallélisable,
j'ai vu des rapports de scalabilité quasi-linéaire jusqu'à 32
processeurs). Il est d'ailleurs conseillé de faire make -j <n+1> avec
n le nombre d'unités de calcul disponibles pour gratter un peu de perf
supplémentaire, je passe les détails techniques qui font que ça
marche.

("man make" pour l'option -j...)

Lionel

Le 17 jan 2008 à 00:53 CET, Lionel Bouton a écrit :

 Si le compilateur n'est pas multithread, le temps de compilation ne
varie guère quel que soit le nombre de processeurs.

Que nenni ! C'est pas à un vieux singe qu'on apprend à faire des
grimaces non plus (cf grep -i 'lionel bouton'
/usr/src/linux/MAINTAINERS).

J'ai compilé le kernel avec make puis make -j2 pour comparer, ce qui
est le standard pour profiter de la présence de plusieurs CPU avec
make.

Si tu n'as jamais essayé de compiler un noyau comme ça sur une
machine
SMP, il est temps d'essayer ! Sur une machine "normale" (i.e. non
bridée) le temps de compilation est quasiment divisé par le nombre
de
processeurs (la compilation du noyau est extrèmement parallélisable,
j'ai vu des rapports de scalabilité quasi-linéaire jusqu'à 32
processeurs). Il est d'ailleurs conseillé de faire make -j <n+1> avec
n le nombre d'unités de calcul disponibles pour gratter un peu de
perf
supplémentaire, je passe les détails techniques qui font que ça
marche.

("man make" pour l'option -j...)

Lionel

Mea culpa, ca fait bien 5 ans que je n'ai pas recompilé un noyau linux
et à l'époque le SMP n'était pas d'usage (du moins pour moi).

En conclusion, y a bien un bridage ou un probleme de configuration Xen

Eric

Le 16 jan 2008 à 23:40 CET, Lionel Bouton a écrit :

Mes benchs me donne l'impression que Gandi a configuré Xen (au moins
pour la beta) pour qu'on ne puisse pas profiter du fait que le reste
de
la machine ne fait rien pour avoir un ou plusieurs processeurs à soi
(par exemple une compilation noyau sur un ou deux processeurs avec 4
parts prend quasiment le même temps, ce qui semble indiquer que la
puissance totale est bridée).
[...]

Je surveille cette tanière depuis un moment, et je me posais la même
question. Que l'on ne "deborde" pas sur toute la machine peut
parfaitement se comprendre, mais rester cloitré quand le CPU se tourne
les pouces est assez regrettable.

Du coup ceci interdit l'utilisation d'appli ayant besoin de consommer du
CPU de temps en temps. Par forcément beaucoup, on sait que ce qui est
garanti correspond à ce qu'on paye, à chacun de faire ses choix. Mais
1/8 de core 100% du temps par part... gloups.

Avoir une réponse claire et officielle sur le sujet serait bien utile
;-)

Sam. wrote:

Du coup ceci interdit l'utilisation d'appli ayant besoin de consommer du
CPU de temps en temps. Par forcément beaucoup, on sait que ce qui est
garanti correspond à ce qu'on paye, à chacun de faire ses choix. Mais
1/8 de core 100% du temps par part... gloups.

A mon avis (ce n'est que mon avis :p), c'est aussi pour éviter la 
situation dans laquelle 50 clients qui auraient pris 4 ou 8 parts vont 
prendre 1 part "en espérant avoir plein de CPU libre", et au final on 
aura des saturations régulières, que l'on connait bien sur les 
mutualissé bas de gamme, et des clients au final pas contents.

Le 17 jan 2008 à 11:34 CET, Xavier Roche a écrit :

A mon avis (ce n'est que mon avis :p), c'est aussi pour éviter la 
situation dans laquelle 50 clients qui auraient pris 4 ou 8 parts vont
prendre 1 part "en espérant avoir plein de CPU libre", et au final on
aura des saturations régulières, que l'on connait bien sur les 
mutualissé bas de gamme, et des clients au final pas contents.

J'ai pensé à la même chose. Mais à chacun de prendre ses
responsabilités. Après faire un bridage technique pour des problèmes
de "com", c'est dommage. (j'avoue que ce n'est pas simple non plus)

Sinon un autre argument auquel j'ai pensé, c'est de limiter les frais.
Moins de CPU utilisé = moins ressources (courant cpu, courant clim,
maintenance clim, ...). A grande échelle ça n'est pas négligeable,
je l'admet volontiers.

Après restera à voir si le prix est justifié en regard de la
performance moyenne d'une part (moyenne au sens mathématique, ce n'est
pas une critique). Il y a déjà un sujet sur le prix, je n'en rajoute
pas.

Sam. wrote:

J'ai pensé à la même chose. Mais à chacun de prendre ses
responsabilités. Après faire un bridage technique pour des problèmes
de "com", c'est dommage. (j'avoue que ce n'est pas simple non plus)

Non pas seulement. A mon avis (là encore à confirmer par les chefs à 
plumes) le bridage a aussi un autre interêt: faire en sorte qu'un ou 
deux utilisateurs ne "bouffent" pas le CPU/réseau libre de 50 autres 
personnes en permanence.

Et donc:
- éviter que quelques utilisateurs payent un service (trop) pas cher en 
profitant des ressources laissées libres par d'autres
- incidemment, cela réduit l'utilisation moyenne des CPU et du réseau, 
et donc cela permet de garder des tarifs rentables (ie. si gandi 
consomme en moyenne 50% de la BP prévue, il payera moins cher, dans la 
mesure où ce qui est probablement payé au carrier, c'est la consommation 
réelle - idem pour le courant électrique, qui est une resource 
probablement aussi coûteuse que la bande passante)

Le 17 jan 2008 à 11:34 CET, Xavier Roche a écrit :

A mon avis (ce n'est que mon avis :p), c'est aussi pour éviter la 
situation dans laquelle 50 clients qui auraient pris 4 ou 8 parts vont

prendre 1 part "en espérant avoir plein de CPU libre", et au final on

aura des saturations régulières, que l'on connait bien sur les 
mutualissé bas de gamme, et des clients au final pas contents.

Euh, c'est déjà le cas, je suis déçu et j'ai pris 4 parts... Je ne
vois pas trop l'avantage de brider lorsqu'on a potentiellement plus de
puissance / BP disponible : là tout se passe comme si tout le monde
chargeait sa part au maximum (réseau + CPU) en permanence, ce qui
n'est jamais le cas en pratique donc on se retrouve avec des
performances réseau et CPU inférieures à ce à quoi je suis habitué
chez les concurrents américains pour une offre toute récente.

En plus avec Xen il est assez facile de repérer les gros consommateurs
de CPU et soit de les répartir dynamiquement sur les machines
physiques pour leur donner de l'air si on désire rendre le service
attractif pour eux, soit au contraire les regrouper sur une même
machine s'ils posent problème pour le modèle d'offre de Gandi.

Lionel

Le 17 jan 2008 à 15:16 CET, Lionel Bouton a écrit :
pas contents.

Euh, c'est déjà le cas, je suis déçu et j'ai pris 4 parts... Je ne
vois pas trop l'avantage de brider lorsqu'on a potentiellement plus de
puissance / BP disponible : là tout se passe comme si tout le monde
chargeait sa part au maximum (réseau + CPU) en permanence, ce qui
n'est jamais le cas en pratique donc on se retrouve avec des
performances réseau et CPU inférieures à ce à quoi je suis
habitué
chez les concurrents américains pour une offre toute récente.

En plus avec Xen il est assez facile de repérer les gros
consommateurs
de CPU et soit de les répartir dynamiquement sur les machines
physiques pour leur donner de l'air si on désire rendre le service
attractif pour eux, soit au contraire les regrouper sur une même
machine s'ils posent problème pour le modèle d'offre de Gandi.

Lionel

+1 pour le principe. Il ne s'agit pas de consommer la part des autres...
mais de profiter ce celles qu'ils n'utilisent pas, et inversement.

Si les parts correspondent à une dispo garantie, personne n'est laisé.
On paye x parts, on a toujours x parts de dispo minimum même si la
charge monte sur les autres machines virtuelles. Si la charge est trop
forte, on est cantonné à ses x parts pour que tout le monde ai ce
qu'il a demandé/payé. Normal.

Après plafonner les ressources maxi n'est pas idiot non plus. C'est un
compromis. Ne jamais pouvoir dépasser l'utilisation d'un core (ou 1/2
core) si on ne paye qu'une part, et monter progressivement la
fourchette en fonction du nombre de part payé. Ainsi la puissance maxi
(non garantie) est aussi fonction du prix, concept légitime. (je n'ai
jamais vu Xen à l'oeuvre, je ne connais pas les possibilité non
plus...).

Pareil pour les ressources réseaux, surtout si ça génère un coup au
volume. Inutile de vouloir "tout pour rien", nous sommes bien d'accord
;-)

Le jeu, 17 jan 2008 at 14:16 GMT, Lionel Bouton <lionel-subscription@bouton.name> a écrit :

En plus avec Xen il est assez facile de repérer les gros consommateurs
de CPU et soit de les répartir dynamiquement sur les machines
physiques pour leur donner de l'air si on désire rendre le service
attractif pour eux, soit au contraire les regrouper sur une même
machine s'ils posent problème pour le modèle d'offre de Gandi.

Ce n'est meme pas forcément nécessaire de les isoler.
Xen fait très bien la répartition équitable, de façon à ce qu'un
"nouveau" ayant besoin de capacité CPU trouve sa place par rapport à sa
quote-part.
Là, c'est plafonné en permanence, alors que ça pourrait n'etre plafonné
que quand c'est nécessaire.

Sam. wrote:

+1 pour le principe. Il ne s'agit pas de consommer la part des autres...
mais de profiter ce celles qu'ils n'utilisent pas, et inversement.

Vous n'avez pas tout lu: le problème amha est de consommer des 
ressources qui n'auraient pas été consommées sinon, notamment niveau 
bande passante.

Cela n'impacte pas les autres utilisateurs, sauf que, au final, la bande 
passante globale augmente, et donc les coûts.

Mais bon, il y a probablement d'autres raisons (techniques ?)

Le 16 jan 2008 à 23:01 CET, macgiver a écrit :

Bonjour, j'ai fait un rapide bench comparatif entre 1 part et ma
machine
(ATHLON XP 2400+, pas tout jeune) et je trouve un rapport de 7,7. Ce
qui
n'est pas flatteur ...

Moi aussi je suis extrêmement déçu par ce bridage. Mes besoins sont
très modestes (en nombre d'accès, espace disque, bande passante...
bref ma part, si je la garde, sera idle 99% du temps) mais de temps à
autre il y a une tâche substantielle à effectuer et je n'ai pas envie
que ça traîne en longueur. Il est hors de question que j'achète plus
d'une part, car ce serait financièrement disproportionné par rapport
aux besoins.

Le 20 jan 2008 à 02:24 CET, Antoine a écrit :

Le 16 jan 2008 à 23:01 CET, macgiver a écrit :

Bonjour, j'ai fait un rapide bench comparatif entre 1 part et ma
machine
(ATHLON XP 2400+, pas tout jeune) et je trouve un rapport de 7,7. Ce
qui
n'est pas flatteur ...

Moi aussi je suis extrêmement déçu par ce bridage. Mes besoins sont
très modestes (en nombre d'accès, espace disque, bande passante...
bref ma part, si je la garde, sera idle 99% du temps) mais de temps à
autre il y a une tâche substantielle à effectuer et je n'ai pas
envie
que ça traîne en longueur. Il est hors de question que j'achète
plus
d'une part, car ce serait financièrement disproportionné par rapport
aux besoins.

Les parts sont effectivements cloisonnées pour vous garantir les
ressources que vous
demandez à tout moment. Vous avez ni plus ni moins de puissance que le
nombre de parts
que vous avez choisi. Prochainement, le service Gandi Flex vous
permettra d'obtenir temporairement
et automatiquement plus de ressources en fonction de vos besoins du
moment.

Nicolas

\o/ Nicolas Lhuillery
 G  GANDI