Points de contrôle/en: Difference between revisions

From Alliance Doc
Jump to navigation Jump to search
No edit summary
No edit summary
Line 7: Line 7:
However, if you have access to the source code of the software and/or if you are the author, you can implement a checkpoint/restart functionality in the program yourself. The essential steps are:
However, if you have access to the source code of the software and/or if you are the author, you can implement a checkpoint/restart functionality in the program yourself. The essential steps are:


* La création d'un fichier de point de contrôle se fait de façon périodique. On suggère des périodes de 2 à 24 heures
* The creation of a checkpoint file is done periodically, with a suggested frequency of every 2 to 24 hours
* Pendant l'écriture du fichier, il faut garder en tête que la tâche de calcul peut être interrompue à tout moment, et ce, pour toute sorte de raison technique. Par conséquent:
* While writing the checkpoint file, it's important to remember that the program could be interrupted at any moment and this for a variety of reasons. As a consequence,
** Il est préférable de ne pas écraser le précédent point de contrôle en créant le nouveau
** It is preferable to not delete the preceding checkpoint when creating the new one.
** On peut rendre l'écriture ''atomique'' en effectuant une opération qui vient confirmer la fin de l'écriture du point de contrôle. Par exemple, on peut initialement nommer le fichier en fonction de la date et l'heure et, finalement, créer un lien symbolique "derniere-version" vers le nouveau fichier de point de contrôle ayant un nom unique. Autre méthode plus avancée : on peut créer un second fichier contenant une somme de hachage du point de contrôle, permettant ainsi de valider l'intégrité du point de contrôle à son éventuel chargement
** The creation of the checkpoint file can be made ''atomic'' by performing an operation which confirms the end of the checkpoint process. For example, the checkpoint file can be initially named based on the date and time and, as the final step, a symbolic link ''latest-version'' is pointed at this new checkpoint file. Another more advanced method would be to create a second file which contains a hash of the checkpoint file's content by means of which the restart function can verify the integrity of the checkpoint when it is loaded.
** Une fois l'écriture atomique complétée, on peut décider de supprimer ou non des vieux points de contrôle
** Once the atomic write has been completed, one can choose whether or not to delete any older checkpoints.


Afin de ne pas réinventer la roue, surtout si la modification du code source n'est pas une option, nous suggérons l'utilisation de [http://dmtcp.sourceforge.net/ DMTCP].
Afin de ne pas réinventer la roue, surtout si la modification du code source n'est pas une option, nous suggérons l'utilisation de [http://dmtcp.sourceforge.net/ DMTCP].

Revision as of 15:25, 21 August 2017

Other languages:

The execution time for a program is sometimes too long for the maximum duration of a job permitted by the job schedulers used on Compute Canada clusters. Long-running jobs are also subject to all of the risks of system instability due to power outages, hardware defects and so forth. A program with a short execution time can easily be restarted with little concern but for long-running software it is preferable to use checkpoints to minimize the risk of losing several days' worth of computation. These checkpoints take the form of binary disk files from which the program can be restarted at the point in the computation where the checkpoint file was initially created.

Creating and Loading a Checkpoint

The creation and loading of a checkpoint may already be taken care of by the application you're using. In this case you simply need to read the relevant documentation about how to use this functionality.

However, if you have access to the source code of the software and/or if you are the author, you can implement a checkpoint/restart functionality in the program yourself. The essential steps are:

  • The creation of a checkpoint file is done periodically, with a suggested frequency of every 2 to 24 hours
  • While writing the checkpoint file, it's important to remember that the program could be interrupted at any moment and this for a variety of reasons. As a consequence,
    • It is preferable to not delete the preceding checkpoint when creating the new one.
    • The creation of the checkpoint file can be made atomic by performing an operation which confirms the end of the checkpoint process. For example, the checkpoint file can be initially named based on the date and time and, as the final step, a symbolic link latest-version is pointed at this new checkpoint file. Another more advanced method would be to create a second file which contains a hash of the checkpoint file's content by means of which the restart function can verify the integrity of the checkpoint when it is loaded.
    • Once the atomic write has been completed, one can choose whether or not to delete any older checkpoints.

Afin de ne pas réinventer la roue, surtout si la modification du code source n'est pas une option, nous suggérons l'utilisation de DMTCP.

DMTCP

Le logiciel DMTCP (Distributed Multithreaded CheckPointing) permet de faire des points de contrôles de programmes sans avoir à les recompiler. Pour pouvoir l’utiliser, il faut charger le module DMTCP. La première exécution est effectuée avec le programme dmtcp_launch en spécifiant le temps entre les intervalles de sauvegarde. Le redémarrage se fait en exécutant le script dmtcp_restart_script.sh. Par défaut, ce script et les fichiers de redémarrage du programme sont écrits à l'endroit où le programme a été lancé. On peut changer l’emplacement des fichiers de sauvegarde avec l’option --ckptdir <répertoire pour les sauvegardes>. Vous pouvez faire dmtcp_launch --help pour obtenir toutes les options. Notez que DMTCP ne marche pas pour le moment avec les logiciels parallélisés par MPI.

An example of a job script:

Fichier : job_with_dmtcp.sh

#!/bin/bash
# ---------------------------------------------------------------------
# SLURM script for job resubmission on a Compute Canada cluster. 
# ---------------------------------------------------------------------
#SBATCH --job-name=job_chain
#SBATCH --account=def-someuser
#SBATCH --cpus-per-task=1
#SBATCH --time=0-10:00
#SBATCH --mem=100M
# ---------------------------------------------------------------------
echo "Current working directory: `pwd`"
echo "Starting run at: `date`"
# ---------------------------------------------------------------------
# Run your simulation step here...

if test -e "dmtcp_restart_script.sh"; then 
     # There is a checkpoint file, restart;
     ./dmtcp_restart_script.sh -h `hostname`
else
     # There is no checkpoint file, start a new simulation.
     dmtcp_launch --rm  -i 3600 -q <programme> <arg1> ... <argn>
fi

# ---------------------------------------------------------------------
echo "Job finished with exit code $? at: `date`"
# ---------------------------------------------------------------------


Resoumettre une tâche pour un calcul de longue durée

Si on prévoit qu'un long calcul sera morcelé en plusieurs tâches Slurm, les deux méthodes recommandées sont: