IMB > cellule > Calcul et Développement > PlaFRIM2 (Archives)

PlaFRIM2 - avancé : gros travaux segmentables ou besoin de réactivité (testpreempt)

[rouge]Attention : cet article concerne feu la plateforme PlaFRIM2[/rouge]

Présentation de la file "testpreempt"

Une file en test "testpreempt" permet de lancer des jobs au delà des limites habituelles de façon à pouvoir exploiter au mieux les cœurs non utilisés (la journée mais surtout la nuit et le week end) sans pénaliser les jobs respectant les contraintes des files standards.

Le prix à payer pour cela est que ces jobs peuvent être arrêtés ("préemptés") brutalement à tout moment si un job régulier peut démarrer.

Votre job est ensuite redémarré quand de la place s’est libérée. (ne semble pas fonctionner actuellement)

Votre code doit donc sauvegarder très régulièrement son état ("checkpoint") en garantissant l’intégrité de cette sauvegarde (au cas où le job soit interrompu pendant la sauvegarde) et être capable de repartir depuis cette sauvegarde.

Pour éviter que cette file ne soit utilisée par mégarde et qu’elle ne trouble les utilisateurs des files standards, elle n’apparaît pas naturellement dans les commandes sinfo et squeue : l’option -a est nécessaire pour la voir.
Pour démarrer les tests, les paramètres suivants ont été retenus (ils sont susceptibles d’évoluer par la suite) :
Le temps d’exécution d’un job dans cette file est limité à 8h
Tous les nœuds sont accessibles via cette file, si vous souhaitez cibler des nœuds particuliers, utilisez l’option --constraint
ex :

Pour avoir la liste des contraintes utilisables, utilisez la commande suivante : sinfo -o "%30N %10c %10m %30f %10G" (colonne FEATURES)

Conseils pour la sauvegarde de l’état de votre job (checkpointing)

Écrire une fonction dédiée à cette tache ainsi qu’une fonction dédiée à la restauration des données à partir de la sauvegarde.

Sauvegarder l’état de votre programme dans un fichier temporaire (ou dans plusieurs fichiers dans un répertoire temporaire) puis renommer (opération atomique) avec le nom définitif ce fichier (ou répertoire) temporaire de façon à "valider" la sauvegarde.

de cette façon, si votre job est interrompu pendant pendant la sauvegarde de son état, cela n’aura pour effet que de générer un fichier (ou répertoire) temporaire inutilisé. La précédente sauvegarde sera toujours cohérente et c’est elle qui sera reprise pour redémarrer le job.

Quand votre job démarre il doit regarder en premier s’il existe un état sauvegardé et si oui, repartir de cet état.

La sauvegarde de l’état se fait typiquement derrière un point de synchronisation MPI pour être sûr que toutes les instances de votre code fassent leur sauvegarde en même temps.

La fréquence de ces sauvegardes est à adapter en fonction de sa durée (temps d’écriture des données). Pour donner un ordre de grandeur, votre code ne devrait pas tourner plus de 30 minutes à 1 heure sans faire de sauvegarde.