Discussion :

[sedawk]

Bonjour à tous,

je rencontre actuellement un soucis concernant un tir de performance, je m'explique :

La machine que j'ai actuellement (AIX 5.3 TL12) est d'origine configurée ainsi :
-0,4 EC
-1 VCPU
- Mode SMT2
-2 CPU logique
-mode Uncapped

Lors des test je m'aperçois que ça ne va pas du tout et que c'est trop lent, je ragarde les courbes NMON, et je vois que la CPU travaille beaucoup, elle dépasse même la CPU garantie qui lui a été allouée, (monte à 1,2 EC constamment), je me dit OK il faudra en rajouter, puis je jette un coup à la runqueue, là je vois 70-80 thread en attente de cycle CPU, il est clair qu'il faut pas chercher midi à 14h....

D'après ce que j'ai pu voir, chaque runqueue par processeur peut prendre en charge maxi 5 threads, ce qui nous fait donc ici 5X2=10 threads au mieux, il est évident que cela est largement insuffisant pour 70-80 threads.

Je me dis donc qu'il faut rajouter de la CPU, et de la VCPU, donc je passe de 0,4EC à 1,4EC, ce qui me fait en vcpu max 14 (10x entitlement il me semble ?)
et ce qui ferait pas conséquent 14X2 = 28 cpus logiques et donc théoriquement prendre en charge 28X5= 140 threads (vous me dites si je me trompe ?)

La runqueue étant saturée à 80% je me dis que je vais mettre 12 VCPU pour 120 threads de gérable, or quand je refait les tests, je m'aperçois que sur les 12 vcpus de configurés seul 4 travaillent, et la runqueue est toujours à 70 threads en attente, comment est-ce possible ? Pourquoi le kernel ne dispatche pas le travaille sur les autres VCPUs ?

Ma théorie serait qu'un thread s'accapare tout le temps CPU, mais il serait en attente de quelque chose qui n'arrive jamais, ce qui fait que les autres threads s'accumulent en entendant que leurs tours, dès lors peut-on se dire que l'appli qui à générer ce thread est mal écrit ?

Merci pour vos réponses.

[matafan]

Ca ne sert à rien de mettre plus de CPU virtuels que tu n'as de ressources physiques utilisables par ta machine. Les CPU virtuels additionnels ne seront pas utilisés et seront potentiellement "foldés". Au final tu te doutes bien que ce sont les ressources physiques qui te limitent.

Dans ton cas puisque seuls 4 VCPUs travaillent (en supposant que tu parles bien de CPUs virtuels et pas de CPU logiques, mais j'ai un doute), ça veut probablement dire que tu n'as que 4 CPUs physiques dans ton pool.

Pour répondre à ta question "Pourquoi le kernel ne dispatche pas le travaille sur les autres VCPUs", c'est parce que ces VCPUs ne sont eux-même pas dispatchés sur un CPU physique.

[sedawk]

matafan, merci pour ta réponse qui m'a permi de mieux m'aiguiller vers l'origine du problème, en effet en jetant un coup d'oeil au share pool de 16 CPU, je me suis rendu compte que ce dernier était saturé, la machine configurée à 1.4EC allait cherchait jusqu'à max 2.0EC (ca dure moins d'une minute car je suppose qu'après une autre machine l'a récupérée dès que la mienne avait fini), car il restait tout simplement 0.6 EC de libre et que ce n'était suffisant (on voyait largement que la machine en avait besoin de plus)

Cela explique pourquoi le nombre de VCPU diminuaient et pourquoi il y avait autant de thread dans la runqueue.

Par contre j'ai un doute concernant ta phrase :

"Dans ton cas puisque seuls 4 VCPUs travaillent (en supposant que tu parles bien de CPUs virtuels et pas de CPU logiques, mais j'ai un doute), ça veut probablement dire que tu n'as que 4 CPUs physiques dans ton pool."

Oui ce sont bien les VCPU et non des logicals dont je parlais, par contre supposer que si 4 VCPUs travaillent cela impliquerait qu'il n'y est que 4 CPUs physique dans le pool n'est pas correct je pense, car étant donnée que le nombre max de vcpu=10xEC, cela signifierait que si j'ai 20 VCPU pour 2 cpu physiques, cela impliquerait qu'il y ait que 20 CPU physiques dans le pool ?

Je pense que la vcpu ne dépend pas du pool, mais qu'il est limité par l'EC qui a été configuré initialement et lui par contre dépend du pool si ce dernier venait à saturer.

Qu'en penses-tu ?

[matafan]

Tu peux effectivement mettre autant de VCPU que tu veux, à partir du moment où tu as au moins 0.1 d'entitlement par VCPU. C'est donc bien l'entitlement qui limite le nombre de VCPU (et indirectement les CPUs, physiques, puisque la somme des EC de toutes les partitions qui piochent dans le pool ne peux pas dépasser la taille du pool).

Cependant à chaque instant tu n'aura jamais plus de VCPUs qui travaillent que de CPUs physiques dans ton pool. Pour reprendre ton exemple, tu peux effectivement configurer 20 VCPUs avec une EC de 2 et 2 CPU physiques dans ton pool. Mais si tu fais ça tu aura en permanence 18 VPCUs qui seront inutilisés, et c'est donc inutile voire néfaste pour les performances.

La raison pour laquelle tu peux aller jusqu'à VCPUs = 10 x EC, c'est pour permettre aux VCPUs de tourner sur un dixième de CPU physique, rien de plus. L'intéret ce n'est pas de pouvoir faire VCPU = 20 avec deux CPU dans le pool, c'est de pouvoir faire des choses du genre :

- VCPU = 1, EC = 0.1
- VCPU = 2, EC = 0.2, uncapped, avec au moins 2 CPUs dans le pool
- VPUC = 20, EC = 2, uncapped, avec au moins 20 CPUs dans le pool