Les tâches de l’utilisateur peuvent demander des ressources, mais pendant l’exécution, les processeurs entièrement demandés ne sont pas utilisés par les JOBS. Il peut y avoir de nombreuses raisons pour expliquer ce comportement :

(a) Des erreurs dans les fichiers de lot SLURM.

(b) Le code/l’application n’est pas bien parallélisé.

(c) Des besoins locaux en mémoire supplémentaire par processeur.

(d) L’utilisateur souhaite exécuter un code séquentiel.

Pour tous ces événements, l’utilisateur devrait vérifier les performances de ses JOBS en utilisant une fonction système appelée « jobcpuload ». Cette fonction rapporte l’utilisation moyenne du processeur (CPULoad) et la capacité du processeur disponible (CPUTot) des nœuds par JOB. Si CPULoad atteint la valeur de CPUTot, le JOB utilise presque tous les processeurs du nœud ; cependant, pour une raison quelconque, si CPULoad est inférieur à CPUTot, le JOB est déséquilibré et les JOBS de l’utilisateur font perdre du temps CPU et des ressources dans EXPLOR.

Par conséquent, les utilisateurs devraient maximiser le CPULoad de leurs exécutions afin d’éviter d’exécuter de nombreux JOBS déséquilibrés qui n’utilisent pas toutes les ressources allouées. Dans les cas où le code présente de mauvaises performances parallèles, l’utilisateur doit regrouper plusieurs tâches en une seule exécution de lot SLURM plutôt que de soumettre de nombreux JOBS qui allouent peu de processeurs.