Architecture du calculateur¶
Voir l'utilisation du calculateur : Utilisation.
jarvis n'est pas une machine de type SMP (Symmetric multiprocessing) où l'accès des coeurs de calcul à la mémoire commune serait uniforme pour tous les coeurs.
Le calculateur est physiquement constitué de multiples lames de calcul, chaque lame (socket) ayant sa propre quantité de mémoire (384Go). C'est grâce à la technologie d'interconnection des lames (NUMAlink) et aux des spécificité du calculateur que cet ensemble de mémoires physiquement distribuées devient accessible et partagé entre tous les coeurs de calculs et au sein d'un seul système d'opération (un seul système Linux suffit à gérer l’ensemble des ressources processeurs et mémoire).
jarvis ressemble donc du point de vue matériel à un cluster de calcul (= machine à mémoire distribuée), mais il a les fonctionnalités d'une machine à mémoire partagée (un seul système, adressage à tout l'espace mémoire).
Ainsi, pour un processeur donné, les temps d'accès à une zone mémoire diffèrent suivant la zone mémoire accédée, d'où le nom de machine NUMA (pour Non Uniform Memory Access ou Non Uniform Memory Architecture).
Bien qu'on bénéficie d'un réseau NUMAlink performant et de lames ultra-denses à hautes performances, l'utilisateur ne doit pas oublier/ignorer qu'il travaille sur une architecture NUMA et pour qu'il obtienne de bonnes performances et une reproductibilité des temps CPU, il doit positionner les processus correctement sur les ressources disponibles et utiliser certaines commandes spécifiques (outils linux : numactl,hwloc).
[homer@jarvis ~]$ cpumap Thu Nov 28 08:54:35 AM CET 2024 jarvis model name : Intel(R) Xeon(R) Platinum 8468H Architecture : x86_64 cpu MHz : 3800.000 cache size : 107520 KB (Last Level) Total Number of Sockets : 16 Total Number of Cores : 768 (48 per socket) Hyperthreading : OFF =============================================================================
- la commande
numactl -H(--hardware) permet de visualiser la distance entre les sockets :
[homer@jarvis ~]$ numactl -H available: 16 nodes (0-15) ... node distances: node 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 0: 10 16 16 18 40 40 40 40 40 40 40 40 40 40 40 40 1: 16 10 18 16 40 40 40 40 40 40 40 40 40 40 40 40 2: 16 18 10 16 40 40 40 40 40 40 40 40 40 40 40 40 3: 18 16 16 10 40 40 40 40 40 40 40 40 40 40 40 40 4: 40 40 40 40 10 16 16 18 40 40 40 40 40 40 40 40 5: 40 40 40 40 16 10 18 16 40 40 40 40 40 40 40 40 6: 40 40 40 40 16 18 10 16 40 40 40 40 40 40 40 40 7: 40 40 40 40 18 16 16 10 40 40 40 40 40 40 40 40 8: 40 40 40 40 40 40 40 40 10 16 16 18 40 40 40 40 9: 40 40 40 40 40 40 40 40 16 10 18 16 40 40 40 40 10: 40 40 40 40 40 40 40 40 16 18 10 16 40 40 40 40 11: 40 40 40 40 40 40 40 40 18 16 16 10 40 40 40 40 12: 40 40 40 40 40 40 40 40 40 40 40 40 10 16 16 18 13: 40 40 40 40 40 40 40 40 40 40 40 40 16 10 18 16 14: 40 40 40 40 40 40 40 40 40 40 40 40 16 18 10 16 15: 40 40 40 40 40 40 40 40 40 40 40 40 18 16 16 10
- la commande
numastat -mpermet de visualiser les capacités mémoires par socket :
$ numastat -m -c 8
Per-node process memory usage (in MBs) for PID 8 (kworker/0:0H-events_highpri)
Node 0 Node 1 Node 2 Node 3 Node 4 Node 5 Node 6 Node 7 Node 8 Node 9
------ ------ ------ ------ ------ ------ ------ ------ ------ ------
Huge 0 0 0 0 0 0 0 0 0 0
Heap 0 0 0 0 0 0 0 0 0 0
Stack 0 0 0 0 0 0 0 0 0 0
Private 0 0 0 0 0 0 0 0 0 0
------- ------ ------ ------ ------ ------ ------ ------ ------ ------ ------
Total 0 0 0 0 0 0 0 0 0 0
Node 10 Node 11 Node 12 Node 13 Node 14 Node 15 Total
------- ------- ------- ------- ------- ------- -----
Huge 0 0 0 0 0 0 0
Heap 0 0 0 0 0 0 0
Stack 0 0 0 0 0 0 0
Private 0 0 0 0 0 0 0
------- ------- ------- ------- ------- ------- ------- -----
Total 0 0 0 0 0 0 0
Per-node system memory usage (in MBs):
Node 0 Node 1 Node 2 Node 3 Node 4 Node 5 Node 6 Node 7 Node 8
------ ------ ------ ------ ------ ------ ------ ------ ------
MemTotal 380128 381074 381074 381074 381074 381074 381074 381032 381074
MemFree 366348 376349 375194 372885 371920 360499 373289 374721 377890
MemUsed 13780 4725 5880 8188 9153 20575 7785 6311 3184
SwapCached 0 0 0 0 0 0 0 0 0
Active 456 1164 1307 199 2523 460 742 764 156
Inactive 11582 1833 2887 5545 5122 18701 5698 4295 2300
Active(anon) 83 43 76 48 2227 111 188 91 23
Inactive(anon) 33 10 22 36 102 403 128 94 4
Active(file) 373 1121 1231 151 296 349 553 673 133
Inactive(file) 11549 1823 2865 5509 5020 18298 5569 4201 2296
Unevictable 3 0 0 0 0 2 9 0 0
Mlocked 0 0 0 0 0 2 9 0 0
Dirty 0 0 0 0 0 0 0 0 0
Writeback 0 0 0 0 0 0 0 0 0
FilePages 11963 2977 4129 5693 7449 18824 6262 4973 2433
Mapped 22 6 6 13 114 56 121 5 32
AnonPages 63 18 54 36 181 337 180 77 21
Shmem 41 33 33 33 2133 175 139 99 4
KernelStack 9 7 12 7 10 13 9 9 7
PageTables 1 0 0 0 3 4 3 2 1
SecPageTables 0 0 0 0 0 0 0 0 0
NFS_Unstable 0 0 0 0 0 0 0 0 0
Bounce 0 0 0 0 0 0 0 0 0
WritebackTmp 0 0 0 0 0 0 0 0 0
KReclaimable 351 328 293 623 601 399 379 375 93
Slab 1020 742 648 1113 969 698 731 694 280
SReclaimable 351 328 293 623 601 399 379 375 93
SUnreclaim 669 414 355 491 368 298 352 318 187
AnonHugePages 12 8 28 20 118 288 78 44 6
ShmemHugePages 0 0 0 0 0 0 0 0 0
ShmemPmdMapped 0 0 0 0 0 0 0 0 0
FileHugePages 0 0 0 0 0 0 0 0 0
FilePmdMapped 0 0 0 0 0 0 0 0 0
Unaccepted 0 0 0 0 0 0 0 0 0
HugePages_Total 0 0 0 0 0 0 0 0 0
HugePages_Free 0 0 0 0 0 0 0 0 0
HugePages_Surp 0 0 0 0 0 0 0 0 0
Node 9 Node 10 Node 11 Node 12 Node 13 Node 14 Node 15 Total
------ ------- ------- ------- ------- ------- ------- -------
MemTotal 381074 381074 381074 381074 381074 381074 380002 6095120
MemFree 370421 377156 376475 377572 376988 378732 376280 5982718
MemUsed 10653 3918 4599 3502 4086 2342 3722 112402
SwapCached 0 0 0 0 0 0 0 0
Active 132 154 138 557 337 237 185 9511
Inactive 8641 3014 3629 1877 2879 1264 2578 81845
Active(anon) 17 37 32 190 64 96 44 3371
Inactive(anon) 18 40 20 166 188 28 79 1372
Active(file) 114 117 106 368 273 142 141 6141
Inactive(file) 8623 2974 3609 1711 2691 1236 2499 80473
Unevictable 0 0 0 0 0 0 0 14
Mlocked 0 0 0 0 0 0 0 11
Dirty 0 0 0 0 0 0 0 0
Writeback 0 0 0 0 0 0 0 0
FilePages 8742 3095 3719 2099 3022 1382 2690 89452
Mapped 37 20 14 46 63 61 52 667
AnonPages 22 60 46 328 150 118 72 1763
Shmem 4 4 4 20 59 4 49 2836
KernelStack 7 7 7 8 8 8 8 135
PageTables 0 1 1 2 2 1 1 24
SecPageTables 0 0 0 0 0 0 0 0
NFS_Unstable 0 0 0 0 0 0 0 0
Bounce 0 0 0 0 0 0 0 0
WritebackTmp 0 0 0 0 0 0 0 0
KReclaimable 643 105 98 220 155 174 205 5045
Slab 1220 297 294 503 360 394 509 10473
SReclaimable 643 105 98 220 155 174 205 5045
SUnreclaim 577 192 197 283 205 220 304 5428
AnonHugePages 10 30 30 286 92 82 54 1186
ShmemHugePages 0 0 0 0 0 0 0 0
ShmemPmdMapped 0 0 0 0 0 0 0 0
FileHugePages 0 0 0 0 0 0 0 0
FilePmdMapped 0 0 0 0 0 0 0 0
Unaccepted 0 0 0 0 0 0 0 0
HugePages_Total 0 0 0 0 0 0 0 0
HugePages_Free 0 0 0 0 0 0 0 0
HugePages_Surp 0 0 0 0 0 0 0 0
Cpuset¶
Le sous-système cpuset assigne les CPU individuels et les noeuds de mémoire à des groupes de contrôle. Chaque cpuset peut être spécifié en fonction des paramètres suivants, chacun dans un pseudo-fichier différent du système de fichiers virtuel du groupe de contrôle.
Sur jarvis , le mécanisme de cpuset permet de limiter l’exécution des processus d'un job aux seuls cœurs demandés/alloués afin d'isoler les processus appartenants à différents utilisateurs. La soumission des jobs se fait en utilisant cette fonctionnalité pour limiter les ressources demandés via slurm. Chaque calcul disposera uniquement des ressources spécifiées au moment de la soumission dans slurm par les cpuset.
GPU¶
Sur certains socket de la machine est attaché une carte graphique Tesla Ada de dernière génération :
[homer@jarvis]$ nvidia-smi -L GPU 0: NVIDIA L40S (UUID: GPU-...) GPU 1: NVIDIA L40S (UUID: GPU-...)
Ces cartes servent pour le pré/post-traitement des données et le calcul GPU en fonction des besoins et de l'utilisation de la file de calcul visu.
Il n'est pas possible d'utiliser les cartes pour réaliser des calculs sur GPU (deep learning avec tensorflow, pytorch ).
File System¶
Le système de fichier disponible sur jarvis est XFS, mis en place sur des disques SSD NVMe pour une volumétrie utile de 38To.
XFS est adapté pour l'exécution d'opérations d'entrée/sortie (E/S) parallèles grâce à sa conception, qui repose sur des groupes d'allocation. De ce fait, XFS permet une évolutivité extrême des threads d'E/S, de la bande passante du système de fichiers, de la taille des fichiers et du système de fichiers lui-même lorsqu'il couvre plusieurs dispositifs de stockage physiques.
3 partitions sont disponibles pour les données utilisateurs :
/home: espace de connexion et de mise en place des codes, librairies nécessaires aux codes ; Volume de 10To - quota par utilisateur positionné à 200Go/scratch: espace de travail; Volume de 24To - quota positionné à 500Go/data: espace tampon (cf Stockage additionnel)NB: la partition
/scratchn'est pas destiné à l'archivage! les fichiers trop anciens (plus de 90 jours) y sont nettoyés régulièrement par un système automatique!.Précision: L'âge pris en compte pour la suppression automatique correspond à l'horodatage du fichier lui-même. Attention aux fichiers anciens provenant d'une archive ou transférés avec rsync.
Stockage additionnel¶
Pour étendre la solution en terme de stockage, une baie de stockage va prochainement être mise en production.
Utilisation d'iRODS¶
Un module est disponible pour accéder au système de stockage iRODS mis à disposition pour les utilisateurs du MCIA .
Usage¶
- La même procédure que curta est à réaliser pour initialiser les paramètres de connexion :
iinit - Utilisation :
$ module add tools/irods $ ils