Impact de la maintenance du 11 Janvier 2022 sur la soumission des Jobs / Impact on Job Submission dur to maintenance

Nous mettons en place un dispositif spécifique, afin que vos jobs ne soient pas tués lors de la maintenance du 11 Janvier 2022.
En fonction de leur durée, certains jobs pourront être mis en attente jusqu’à la fin de la maintenance électrique.

Explications :

Pour la maintenance du 11 Janvier 2022 :

Si vous lancez un job qui risque de se terminer après StartTime, votre job restera en état PENDING jusqu’à la fin de la maintenance. Il sera automatiquement lancé après la maintenance.

Mais si vous pensez que votre job est suffisamment court pour se terminer AVANT le début de la réservation, vous pouvez ajuster convenablement sa durée en ajoutant l’option --time dans vos en-têtes sbatch.

AIDE

Pour vous aider à calculer le temps disponible avant la prochaine réservation vous pouvez utiliser la commande check-timelimit.sh :

Par exemple :

  1. Je sais qu’une maintenance est prévue bientôt.
  2. Je vérifie combien de temps il reste avec check-timelimit.sh, qui me renvoie 2-10:34:00 (2 jours, 10 heures, 34 mn avant l’arrêt)
  3. Si mon job est trop long, j’attends la fin de la maintenance
  4. Supposons que mon job soit prévu pour une vingtaine d’heures : pour avoir une chance de passer avant, J’introduis dans mon script sbatch la ligne suivante

Attention ! Dans tous les cas la valeur de durée ne peut dépasser les limites de WallTime imposées par les files d’attente : [https://www.calmip.univ-toulouse.fr/spip.php?article608]


In view of the Olympe shutdown on April 12 and 13, in order to avoid to kill jobs in progress during the shutdown, we are setting up a specific slurm reservation. This reservation may impact the submission of your jobs until the shutdown.

This reservation may impact the submission of your jobs until the shutdown.

EXPLANATIONS

Due to maintenance January, 11th 2022 :

If you run a job that is likely to terminate after StartTime, your job will remain in the PENDING state until the maintenance ends. It will be automatically started after maintenance.

But if you think your job is short enough to end before the reservation starts, you can adjust its duration appropriately by adding the --time option in your sbatch headers.

HELP

To help you calculate the time available before the next reservation you can use the check-timelimit.sh command :

For example :

  1. I know there’s a maintenance scheduled soon.
  2. I check how much time is left with check-timelimit.sh, which returns 2-10:34:00 (2 days, 10 hours, 34 min before shutdown)
  3. If my job is too long, I wait for maintenance to finish
  4. Suppose my job is scheduled for about 20 hours : to have a chance of getting through before then, I insert the following line in my sbatch script

Warning ! In all cases the time value cannot exceed the WallTime limits imposed by the queues : [https://www.calmip.univ-toulouse.fr/spip.php?article608]

Voir aussi

La frontale de connexion

Une fois que vous êtes connecté à Olympe, vous êtes sur l’une des trois frontales de connexion : olympelogin1 ou olympelogin2

Pour lancer et suivre ses calculs sur Olympe

Lancer son calcul sbatch mon_script.cmd Quels jobs tournent ? squeue -t RUNNING Où en sont mes jobs ? squeue -u $USER

Organisation des files d’attente

SLURM La gestion des requêtes (job) se fait selon les ressources demandées par la requête (memoire,cpu(s), time limit,etc...). SLURM contrôle les files d’attente, appelées ici QOS (=Quality Of Servic

Réservation interactive en batch

Pour réserver par exemple un nœud en interactif (

Script SLURM pour une réservation de MOINS de 18 cœurs

Réservation des ressources (Exemple pour 5 tâches MPI et 10GB de mémoire)

Script SLURM pour une réservation de PLUS de 18 cœurs

Écrire un script pour un code utilisant plus de 18 cœurs

Script SLURM pour Machine à Mémoire Partagée MESCA

Exemple de script SLURM pour une application OpenMP multithreadée sur 18 threads et ayant besoin de 200 Go (200000 MBytes) de ram globalement adressable:

Script SLURM pour Application OpenMP ou Multithreadée

Nous donnons un exemple de script pour une application purement OpenMP déployant 36 threads. L’argument --cpus-per-task=36 correspond au nombre de cœurs qui seront dédiés aux threads OpenMP.

calcul "embarrassingly parallel": codes non mpi

Cet article explique comment exécuter un programme unique sur un jeu de fichiers en entrée.

calcul "embarrassingly parallel": codes mpi

Lancer avec chdb des traitements mpi

L’accounting

Les algorithmes de calcul de la consommation suivant les ressources que vous utilisez.

Réservation des noeuds GPU

Exemple pour 1 nœud et 9 tâches et 1 GPU Il faut OBLIGATOIREMENT que votre script comporte à minima les informations suivantes :

The chdb tutorial

In this tutorial, you’ll learn how to use chdb to run your embarassingly parallel computations. All the usecases supported by chdb will be described here.

Afficher ma consommation sur Olympe

Cet article décrit les commandes disponibles pour afficher la consommation de son projet, des membres de son projet et des jobs de son projet.

Script SLURM en dépeuplé

Pour des raisons de besoins mémoire par processus MPI ou de nombre de processus MPI égal à une puissance de 2, il peut être intéressant ou nécessaire de déployer sur chaque nœud un nombre de processus MPI inférieur à 36 (sachant que les noœuds d’Ol

L’outil placement

Contrôler le placement d’un job hybride Il est particulièrement important de contrôler le placement de ses threads dans le cas d’un job hybride (openmp + mpi).

Exécution hybride MPI et OpenMP

A travers des exemples nous montrons le moyens d’exécuter des jobs mixtes MPI+OpenMP, en attachant explicitement les processus et les threads aux cœurs physiques des nœuds.

Conteneurs Singularity

Utilisation des conteneurs singularity à Calmip

soumission de jobs avec dépendances

On peut soumettre des jobs, qui ne partiront qu'après la fin d'exécution d'autres jobs.