Ne pas réserver de ressources inutiles
Des commandes peuvent vous aider à définir une réservation adéquate de ressources (CPU, mémoire, walltime). L’intérêt : si le cluster est très utilisé, peu de ressources restent disponibles donc un job qui requiert peu de ressources aura plus de chances de voir son exécution lancée rapidement après sa soumission. De plus, un quota d’heures de calcul annuel est alloué à votre projet et cela vous évitera de consommer des heures inutiles.
Vous pouvez utiliser le « Slurm job efficiency report » (seff) qui vous indique les ressources ayant réellement été utilisées pour exécuter votre job, par rapport à la réservation de ressources initiales.
Pour constater si vous ne réservez pas trop de ressources, lancez la commande ci-dessous, une fois une première exécution du job terminée :
seff <JOBID>
La commande ci-dessous vous permettra de voir quels ont été la consommation mémoire et le temps écoulé pour chaque étape du job. Ainsi, vous pourrez réajuster ces paramètres pour vos prochaines exécutions :
sacct -j <JOBID> --format=jobid,jobname,reqnodes,reqcpus,reqmem,maxrss,averss,elapsed,TotalCPU
De manière plus générale, si vous souhaitez afficher les informations pour tous vos jobs, utilisez cette commande :
sacct -S <START_DATE> --format=jobid,jobname,reqnodes,reqcpus,reqmem,maxrss,averss,elapsed,cputime,time,start,end -u <USERNAME>
La liste complète des champs que vous pouvez afficher est disponible ici.
Définir la mémoire à réserver
Pour définir la mémoire nécessaire à votre job, les options Slurm à votre disposition sont les suivantes :
--mem=
--mem-per-cpu=
--mem-per-gpu=
Par défaut, la valeur spécifiée est considérée être en MégaOctets, mais vous pouvez changer l’unité de mesure en rajoutant à sa suite [K|M|G|T].
J’ai augmenté le nombre de coeurs mais les performances ne s’améliorent pas
Bien qu’une exécution parallèle de code peut permettre d’importants gains de temps par rapport à une exécution sur un seul cœur, vous serez peut-être amenés à remarquer que la rapidité d’exécution de votre code n’augmente pas proportionnellement au nombre de ressources informatiques utilisées. En effet, les portions séquentielles (= non-parallélisables) de votre code ne sont pas sensibles à l’augmentation du nombre de cœurs. Ainsi, en fonction de votre code, à partir d’un certain nombre de ressources l’accélération d’exécution atteindra son seuil maximal et il sera donc inutile de lancer ce code sur davantage de ressources. Pour plus d’informations à ce sujet, voir la loi d’Amdahl.