J'aime beaucoup aussi la slide 6 qui compare le nombre de "threads" des processeurs, ce qui est en général peu pertinent en termes de performance. 36 threads pour un Haswell, avec 2 threads/cœur et 96 threads pour un POWER8, avec 8 threads/cœur. Du coup d'un côté on a 18 cœurs vs 12. Je sais quel processeur va être plus performant (enfin à fréquence équivalente).
ben ce n'est plus un problème de processeur mais un problème d'appli.
Et dans les deux cas j'ai envie de croire que le p8 s'en sortira mieux.
Appli monothread ==> gros cache L3 et L4 & fréquence élevée, donc de grandes chance que ce soit plus performant
Appli multithread ==> 96 threads sur p8, donc plus de slot disponible pour la montée en charge (à condition que l'appli "scale" bien...)
L'autre avantage, c'est de pouvoir consolider un plus grand nombre de VM, donc meilleure densité.
Ça chauffe pas tant que ça un Xeon de nos jours donc grille pain ça semble exagéré quand même. Surtout en face de POWER cadencés à 4+ Ghz, ça doit être autre chose le refroidissement.
Ok pour l'adjectif peu adapté, mais ce que je voulais dire c'est que je préfère moins de serveurs mais mieux utilisés, plutôt que beaucoup et qui ne font rien...parce qu'à la fin, niveau consommation, espace m2, ça finit par être contre-productif.
C'est quoi les fonctionnalités des POWER qui permettent de consolider mieux que sur du Intel (c'est une vrai question, j'en sais rien) ?
l'hyperviseur proprio qui permet d'exploiter le fractionnement de cpu en timeslice.
Contrairement à l'x86, c'est fait en hard car le power a trois niveau d'exécution :
mode hyperviseur / superviseur / utilisateur
Depuis le P7+, on fractionner jusqu'à 0,05, soit 5% d'un core.
Ce qui fait jusqu'à 20VM par core, en supposant que chacune dispose de 0,05 en dédié.
Bien sûr, on peut partager et surtout s'adapter à la charge de travail de chaque VM. C'est le mode shared + uncapped.
Exemple:
Je dispose de 2 core
VM1 ==> 0,2 uncapped jusqu'à 2,00
VM2 ==> 0,05 uncapped jusqu'à 1
Si tout le monde tape dans le pool en même temps, c'est la priorité la plus haute qui bénéficiera des ressources CPU.
Et ce n'est qu'un petit exemple.
Je te laisse imaginer ce qu'on peut faire quand on a plus de 100VM sur le châssis, avec des pool de cpu distinct pour gérer les problème de licence ou de type d'environnement (prod, homol..).
On arrive à un taux de consolidation et d'utilisation très élevés .
Ah et pour finir, les VM n'ont pas de limite en taille de mémoire, si ce n'est le châssis lui-même (mois ce que consomme l'hyperviseur of course).
On peut aussi compresser une partie de la mémoire, exemple j'alloue 100Go en physique à la VM et je lui applique un facteur de compression de 2, l'OS "montrera" 200Go aux applis.
C'est l'OS qui se chargera des swap de pages entre le pool compressé et non compressé.
L'algo de compression s'appuie sur un chipset embarqué dans le cpu (depuis p7+).
Bien sûr, la compression mémoire ne marche pas avec tous les type de workload, il faut prendre des mesures avant etc etc...chose que beaucoup ne font pas :-)
[^] # Re: Power et little endian
Posté par Dabowl_75 . En réponse au journal Debian Jessie, release prévue le 25 Avril avec deux nouvelles architectures. Évalué à 2.
ben ce n'est plus un problème de processeur mais un problème d'appli.
Et dans les deux cas j'ai envie de croire que le p8 s'en sortira mieux.
Appli monothread ==> gros cache L3 et L4 & fréquence élevée, donc de grandes chance que ce soit plus performant
Appli multithread ==> 96 threads sur p8, donc plus de slot disponible pour la montée en charge (à condition que l'appli "scale" bien...)
L'autre avantage, c'est de pouvoir consolider un plus grand nombre de VM, donc meilleure densité.
Ok pour l'adjectif peu adapté, mais ce que je voulais dire c'est que je préfère moins de serveurs mais mieux utilisés, plutôt que beaucoup et qui ne font rien...parce qu'à la fin, niveau consommation, espace m2, ça finit par être contre-productif.
l'hyperviseur proprio qui permet d'exploiter le fractionnement de cpu en timeslice.
Contrairement à l'x86, c'est fait en hard car le power a trois niveau d'exécution :
mode hyperviseur / superviseur / utilisateur
Depuis le P7+, on fractionner jusqu'à 0,05, soit 5% d'un core.
Ce qui fait jusqu'à 20VM par core, en supposant que chacune dispose de 0,05 en dédié.
Bien sûr, on peut partager et surtout s'adapter à la charge de travail de chaque VM. C'est le mode shared + uncapped.
Exemple:
Je dispose de 2 core
VM1 ==> 0,2 uncapped jusqu'à 2,00
VM2 ==> 0,05 uncapped jusqu'à 1
Si tout le monde tape dans le pool en même temps, c'est la priorité la plus haute qui bénéficiera des ressources CPU.
Et ce n'est qu'un petit exemple.
Je te laisse imaginer ce qu'on peut faire quand on a plus de 100VM sur le châssis, avec des pool de cpu distinct pour gérer les problème de licence ou de type d'environnement (prod, homol..).
On arrive à un taux de consolidation et d'utilisation très élevés .
Ah et pour finir, les VM n'ont pas de limite en taille de mémoire, si ce n'est le châssis lui-même (mois ce que consomme l'hyperviseur of course).
On peut aussi compresser une partie de la mémoire, exemple j'alloue 100Go en physique à la VM et je lui applique un facteur de compression de 2, l'OS "montrera" 200Go aux applis.
C'est l'OS qui se chargera des swap de pages entre le pool compressé et non compressé.
L'algo de compression s'appuie sur un chipset embarqué dans le cpu (depuis p7+).
Bien sûr, la compression mémoire ne marche pas avec tous les type de workload, il faut prendre des mesures avant etc etc...chose que beaucoup ne font pas :-)
bref les exemples sont nombreux....