Ada : exécution d'un travail séquentiel en batch

Les travaux sont gérés sur l'ensemble des nœuds par le logiciel LoadLeveler. Ils sont répartis dans des “classes” principalement en fonction du temps Elapsed, du nombre de cœurs et de la mémoire demandés. Vous pouvez consulter ici la structure des classes sur Ada.

Pour soumettre un travail en batch depuis Ada, il faut :

  • Créer un script de soumission :

    pg_seq.ll
    # @ job_type = serial
    # Temps CPU max. d'un processus hhh:mm:ss (1h30mn ici)
    # @ wall_clock_limit=1:30:00
    # Nom du travail LoadLeveler
    # @ job_name = Mono
    # Fichier de sortie standard du travail
    # @ output   = $(job_name).$(jobid)
    # Fichier de sortie d'erreur du travail
    # @ error    = $(job_name).$(jobid)
    # @ queue
    # Pour avoir l'echo des commandes
    set -x
    # On se place dans le repertoire temporaire TMPDIR
    cd $TMPDIR
    # La variable LOADL_STEP_INITDIR est automatiquement positionnee par
    # LoadLeveler au repertoire dans lequel on tape la commande llsubmit
    cp $LOADL_STEP_INITDIR/a.out .
    # Execution du programme
    ./a.out
    ls -lrt
  • Soumettre ce script (uniquement depuis Ada) via la commande llsubmit :

    $ llsubmit pg_seq.ll

Remarques

  • Depuis le 4 mars 2014, nous avons positionné par défaut la variable MP_USE_BULK_XFER à yes pour activer le RDMA. Cette fonctionnalité permet d'accroitre les performances des communications collectives ainsi que le recouvrement calcul/communication. Cependant, quelques codes peuvent avoir des performances réduites lorsque cette variable est positionnée à yes. Vous pouvez désactiver le RDMA pour votre code en valorisant la variable à no juste avant l'exécution de votre binaire (export MP_USE_BULK_XFER=no ou setenv MP_USE_BULK_XFER no).
  • Dans cet exemple, on suppose que l'exécutable a.out se situe dans le répertoire de soumission, c'est-à-dire le répertoire dans lequel on entre la commande llsubmit (la variable LOADL_STEP_INITDIR est automatiquement valorisée par LoadLeveler).
  • Le fichier de sortie du calcul Mono.numero_job se trouve également dans le répertoire de soumission. Il est créé dès le début de l'exécution du travail; l'éditer ou le modifier pendant le déroulement du travail peut perturber celui-ci.
  • Mémoire : la valeur par défaut est de 3.5 Go. La valeur maximale que vous pouvez demander est de 20.0 Go via le mot-clef
    # @ as_limit = 20.0gb.
  • La limite de temps Elapsed associée au mot-clef wall_clock_limit est relative à l'ensemble du job. Il est aussi possible de limiter le temps CPU de chaque commande exécutée dans le job avec le mot-clef cpu_limit. L'utilisation combinée des deux mot-clefs wall_clock_limit et cpu_limit permet d'assurer l'exécution des dernières instructions d'un travail (celles suivant l'exécution de votre binaire) :

    pg_seq.ll
    # @ job_type = serial
    # @ wall_clock_limit=1:00:00
    # @ cpu_limit=45:00
    # @ job_name = myjob
    # @ output = $(job_name).$(jobid)
    # @ error  = $(job_name).$(jobid)
    # @ environment = MY_JOBID=$(jobid)
    # @ queue
    set -x
    # Copy to the TMPDIR the files you need for your computation:
    cp -p ... $TMPDIR
    cd $TMPDIR
    # Run:
    ./my_prog
    ls -alrt
    # Save to the WORKDIR  the result files you are interested in:
    mkdir $WORKDIR/results.${MY_JOBID}
    cp ... $WORKDIR/results.${MY_JOBID}
    # Since the WORKDIR has no backup save to Ergon the important result files
    mfput -v ...

    C'est l'exécution de votre binaire qui consomme l'essentiel des temps Elapsed et CPU du travail. C'est donc votre binaire qui va se heurter à la limite de temps CPU fixée par le mot-clef cpu_limit. Cependant, vous ne connaissez pas à l'avance la durée de cette phase de calcul. De plus, le répertoire TMPDIR étant automatiquement effacé à la fin du travail, vous devez sauvegarder vos fichiers avant cet effacement. Pour être sûr qu'il restera assez de temps pour effectuer les sauvegardes, choisissez une valeur cpu_limit pour le programme suffisamment inférieure à la valeur wall_clock_limit du travail. Un exécutable pouvant voir ses écritures sur disque très ralenties par la charge globale de la machine, le temps Elapsed de l’exécutable my_prog dans le travail va fluctuer mais pas son temps CPU. Il est donc prudent de prendre une marge confortable entre le wall_clock_limit et le cpu_limit. Il n'est pas possible de vous donner une règle de bon sens car le ratio temps CPU/temps Elapsed varie pour chaque exécutable : il vous faudra procéder par essais successifs.