Mémoire (Recommandations)


La plateforme Calculco est un cluster composé de serveurs (nœuds de calcul) multiprocesseurs à mémoire partagée. Ils ont une architecture NUMA et dans cette architecture on parle aussi de nœud mais cela représente cette fois un ensemble "espace mémoire + processeurs (cœurs) + entrées-sorties" au sein d'un même serveur (nœud de calcul).
On utilisera alors par la suite le terme "lame de calcul" au lieu de "nœud de calcul" sur cette page pour ne pas utiliser 2 fois le terme nœud.

Sur calculco, il n'y a pas eu de configuration spéciale concernant la configuration des nœuds mémoire sur nos lames de calcul. Actuellement il y a sur chaque lame de calcul x nœuds mémoire ou x est en fait le nombre de cpu (processeurs) de la lame. Physiquement ce sont les barrettes mémoires des différentes slots de chaque processeur couplé à l'ensemble des cœurs dudit processeur qui forme le nœud mémoire. La construction du nœud mémoire est assez logique.
Chaque cœur peut accéder à la mémoire du nœud mémoire auquel il appartient de manière optimale ou des nœuds mémoire voisins modulo un facteur d'accès pénalisant. Si vous désirez vous rendre compte de cette répartition sur une lame de calcul vous pouvez lancer une réservation interactive par défaut (oarsub -I) et lancer la commande numactl -H.
Vous vous apercevrez par la même occasion que le numéro des cœurs associés à chaque nœud est (modulo le nombre de processeurs de la lame) toujours le même. Le nœud mémoire est composé de tous les cœurs du même processeur.


Sur la plateforme :

Les lames de calcul de orval01 à orval05 et de orval08 à orval11 disposent de 128Go de RAM
La lame orval06 dispose de 64Go de RAM (ancien matériel LOG)
Le lame orval07 dispose de 48Go de RAM (ancien matériel du LISIC)
Les lames récentes financées par le LPCA en disposent plus (384Go pour orval12 et 512Go pour orval13).

Tout ça est visible via l'outil monika, il suffit de sélectionner les propriétés qui vous intéressent pour savoir quel(s) noeud(s) correspond(ent) à vos critères.


Par exemple sur orval01 qui a 4 cpu, pour voir la répartition des nœuds mémoire :

# numactl -H
available: 4 nodes (0-3)
node 0 cpus: 0 4 8 12 16 20 24 28
node 0 size: 32142 MB
node 0 free: 30291 MB
node 1 cpus: 1 5 9 13 17 21 25 29
node 1 size: 32251 MB
node 1 free: 31389 MB
node 2 cpus: 2 6 10 14 18 22 26 30
node 2 size: 32232 MB
node 2 free: 32061 MB
node 3 cpus: 3 7 11 15 19 23 27 31
node 3 size: 32250 MB
node 3 free: 31786 MB
node distances:
node 0 1 2 3
0: 10 20 30 20
1: 20 10 20 30
2: 30 20 10 20
3: 20 30 20 10

Sur orval01 il y a 4 processeurs de 8 cœurs et 128Go de RAM au total. Les cœurs du nœud de mémoire 0 (au nombre de 8) sont tous ceux du processeur 0 et sont numérotés 0,4,8,12,16,20,24,28. Le nœud mémoire dispose du quart de la mémoire totale de la lame de calcul, soit 32Go.
On voit aussi la quantité de mémoire non utilisée de chaque noeud de mémoire.
La compréhension de cette numérotation peut vous être utile aussi lorsque vous regardez les outils de monitoring comme drawgantt et monika. La numérotation des cœurs d'un même processeur n'est pas continue !

Plus généralement, sur calculco, pour chaque lame de calcul, tous les cœurs du nœud de mémoire n (n compris entre 0 et m-1 processeurs de la lame) sont égaux à n (modulo m). Le nœud de mémoire dispose du total de mémoire de la lame de calcul divisé par m.

Mais comment se traduit tout cela lorsque je lance une réservation. Pourquoi m'arrive t'il de swapper alors que je n'utilise pas toute la mémoire disponible de la lame de calcul !

En fait le gestionnaire de ressources et de tâches OAR via le mécanisme des cpusets va confiner votre réservation aux ressources demandées. Il peut donc y avoir un problème dans la quantité de mémoire disponible pour votre tâche si vous n'utilisez pas tous les nœuds mémoire dans votre réservation. Cela n'est pas explicite dans la réservation et c'est là que le bât blesse.

Par exemple sur cette même lame orval01 (qui dispose de 4 processeurs de 8 cœurs) vous voulez lancer une réservation de 8 cœurs de calcul sans être trop explicite (par exemple en interactif oarsub -I -I /core=8 -p "host='orval01'"), vous ne saurez alors pas comment sont répartis les cœurs de votre réservation, il se peut que ce soient tous les cœurs d'un même processeur. C'est d'ailleurs souvent le cas quand la lame de calcul n'est pas ou très peu utilisée. Vous n'aurez alors accès qu'à un seul nœud mémoire (celui affecté au seul processeur que vous utilisez) et donc au max 32Go avant de swapper.

Pour être sûr de pouvoir utiliser toute la mémoire de la lame orval01, il faut faire intervenir tous les nœuds mémoire dans notre réservation et donc répartir les cœurs réservés sur les 4 processeurs. Ça peut être fait via la commande oarsub -I -I /cpu=4/core=2 -p "host='orval01'". On réserve alors 2 cœurs sur chaque processeur de la lame (donc toujours 8 cœurs en tout). On a accès au 4 nœuds mémoire et on peut donc utiliser potentiellement toute la mémoire de la lame de calcul. Idem, si on n'utilise que 2 processeurs (oarsub -I -I /cpu=2/core=4 -p "host='orval01') on aura alors accès uniquement à un max de 64Go de RAM.


Essayer les commandes précédentes quand c'est possible (ou utiliser une autre lame de calcul si orval01 n'est pas disponible).

# oarsub -I -l /cpu=1/core=8 -p "host='orval01'"
[ADMISSION RULE] Set default walltime to 7200.
[ADMISSION RULE] Modify resource description with type constraints
[ADMISSION RULE] Automatically add constraint to go on nodes permitted for the user.
OAR_JOB_ID=637830
Interactive mode: waiting...
Starting...

Connect to OAR job 637830 via the node orval01


Vérifier alors les cœurs et nœuds mémoire affectés à votre réservation :

# cat /proc/self/cpuset
/oar/dverhaghe_637830

# cat /dev/cpuset/oar/dverhaghe_637830/cpuset.cpus
2,6,10,14,18,22,26,30

# cat /dev/cpuset/oar/dverhaghe_637830/cpuset.mems
2

On voit bien qu'on utilise tous les cœurs du processeurs 2 et uniquement le nœud mémoire 2. Donc au max 32Go.


Par contre si on utilise 2 processeurs :

# oarsub -I -l /cpu=2/core=4 -p "host='orval01'"
[ADMISSION RULE] Set default walltime to 7200.
[ADMISSION RULE] Modify resource description with type constraints
[ADMISSION RULE] Automatically add constraint to go on nodes permitted for the user.
OAR_JOB_ID=637831
Interactive mode: waiting...
Starting...

Connect to OAR job 637831 via the node orval01


On peut aussi vérifier les cœurs et nœuds mémoires affectés à notre réservation :

# cat /dev/cpuset/oar/dverhaghe_637831/cpuset.cpus
0,12,16-17,20-21,25,29

# cat /dev/cpuset/oar/dverhaghe_637831/cpuset.mems
0-1

On voit cette fois qu'on utilise les cœurs 0,12,16 et 20 du processeur 0 (modulo 4 sur les numéros de cœurs)  et les cœurs 17,21,25 et 29 du processeur 1 (modulo 4 sur les numéros de cœurs).
Par contre on utilise ici les nœuds mémoire 0 et 1 et on pourra donc accéder à 64Go de RAM

 

De même si on utilise les 4 processeurs :

# oarsub -I -l /cpu=4/core=2 -p "host='orval01'"
[ADMISSION RULE] Set default walltime to 7200.
[ADMISSION RULE] Modify resource description with type constraints
[ADMISSION RULE] Automatically add constraint to go on nodes permitted for the user.
OAR_JOB_ID=637832
Interactive mode: waiting...
Starting...

Connect to OAR job 6378302 via the node orval01


Si on vérifie les cœurs et nœuds mémoire :

# cat /dev/cpuset/oar/dverhaghe_637832/cpuset.cpus
0,10-12,14-15,17,21

# cat /dev/cpuset/oar/dverhaghe_637832/cpuset.mems
0-3

On utilise les cœurs 0 et 12 du processeur 0, 17 et 21 du processeur 1, 10 et 14 du processeur 2 et 11 et 15 du processeur 3
On a accès cette fois à tous les nœuds mémoire, soit 128Go.

 

Conclusion :


Lorsque vous savez pertinemment que vous utiliserez beaucoup de mémoire lors de l’exécution de votre tâche, il faut absolument faire intervenir tous les processeurs de la lame de calcul, et ce même si vous n'avez pas besoin de tous les cœurs de calcul.
A l'extrême, même si vous avez une tâche séquentielle sur 1 cœur qui nécessite beaucoup de mémoire, il faudra réserver toute la lame de calcul pour être sûr de ne pas swapper !!

Nous sommes conscient que ce n'est pas un fonctionnement transparent et qu'il faudra qu'on modifie cela afin que cela devienne plus intuitif et logique pour les utilisateurs.


Une piste serait de créer des bancs mémoire virtuels pour chaque cœurs de la lame de calcul. On pourrait par défaut diviser le nombre total de mémoire de la lame de calcul par le nombre de cœurs dont elle dispose et on affecterait un nœud mémoire par cœur.
Par exemple pour orval01 toujours, on créerait 32 nœuds mémoire de 4Go affectés chacun à un cœur. Si on utilisait alors c cœurs dans notre réservation, on aurait accès à c x 4Go de RAM.

Si vous avez d'autres idées, n'hésitez pas à nous contacter. Idem, si vous ne désirez pas qu'on change le mode de fonctionnement actuel.


 

Politique de réservation  precedent          suite  Statistiques