Ceci est une ancienne révision du document !


GridEngine

Under contruction…

The job scheduler (or batch-queuing system) used in PSMN cluster is SGE,-previously Sun Grid Engine and now Son of Grid Engine-; it manages the execution of non-interactive jobs.

Infrastructure:

  • the compilation servers are described here
  • the cluster hardware configuration is described here
  • the queues for job submission are described here

Optimum use of resources

To make the best use of resources, it is important to fill up the servers. For this, they are two strategies:

  • fill in “at best” (a best effort strategy),
  • fill in with multiple of n cores (where n is the number of physical cores per server).

Filling at best quickly leads to a fragmentation between the servers, of parallel applications via mpi.

Filling at best is therefore only implemented on a few queues for parallel applications. On other queues, the fill in with the multiple of n cores of an entire server is used.

Priorities

Job priority is:

  • inversely proportional to the calculation time already consumed,
  • proportional to waiting time and number of hearts requested.

This is to distribute the available resources more equitably.

GridEngine : Submitting jobs

The normal way to submit jobs to the cluster is using the qsub command. For example:

qsub myscript.sh

The many options to the qsub command are described in the manpage, man qsub.

For example a more complex submission:

qsub -V -m b -m e -e /path/to/workdir/ -o /path/to/workdir/ -q $QUEUE script
 
-V : export environment variables
-m b : mail @begin
-m e : mail @end
-e : where to put error files
-o : where to put output files
-q : queue (file d'attente)

Nevertheless, it is easier to directly submit to GridEngine a script containing the desired options. You can follow the documentation on how to submit a job (full documentation). Moreover take a look at the list of available queues for submission.

Comment choisir les files d'attente, de test ou de productions, adaptées ?

De par les achats successifs de nœuds de calcul avec des architectures de génération différente, il n'était pas possible de définir une seule file d'attente. Il est préférable d'avoir des files d'attentes différentes pour chaque architecture, afin d'atteindre des performances intéressantes pour chaque file d'attente.

Concrètement le choix de la file d'attente de “production” devrait se faire en fonction de l'objectif voulu :

  • si le critère principal est la rapidité de l'exécution, il faut regarder quelles sont les files d'attentes disponibles pour recevoir le job. L'utilisation des commandes du type qstat -g c devraient être la base de ce choix.
  • si le critère principal est le grand nombre de ressources (p.ex. un job avec beaucoup de cœurs, un job avec beaucoup de mémoire RAM), alors il faut plutôt s'orienter vers les files d'attentes qui possèdent un grand nombre de ressources (au moins les ressources demandées par le job), même si le temps d'attente dans la file d'attente est plus important.

Évidemment, la commande ci-dessus et la liste des files d'attente devraient guider votre choix.

Et bien sur, pour la mise au point du code, il faut choisir une file d'attente de test qui soit la plus proche de la file d'attente de “production” envisagée (i.e. même type de nœuds de calcul). P.ex. r815lin128ib a été choisie pour la file d'attente de production, il faut choisir r815_ib_test pour les tests.

GridEngine : Les autres commandes utiles

Checking job status

  • display job status of a specific user:
qstat -u login 
  • display queues status (and list of queues):
qstat -g c 
  • display the running jobs of all users:
qstat -u "*" -s r 
  • display the pending jobs of all users:
qstat -u "*" -s p 
  • display the status of a job in progress:
qstat -j <job_id> | less 
  • display the status of a job in progress with more details (longer):
qstat -j <job_id> -g t | less 
  • display the status of a job in progress with even more details (even longer):
qstat -j <job_id> -g t -s r | less 
  • display information on a job afetr its completion (long):
qacct -j <job_id> -f /gridware/psmn/accounting | less
  • delete a job:
qdel <job_id> 
  • delete a job (force deletion) :
qdel -f <job_id> 

Accounting

Le fichier d'accounting est diffusé sur /gridware/psmn/accounting
  • Détails des jobs sur les 30 derniers jours :
qacct -f /gridware/psmn/accounting -d 30 -o <login> -j 
  • Consommation d'heures CPU (utime sur les 30 derniers jours) :
qacct -f /gridware/psmn/accounting -d 30 -o <login> | tail -1 | awk '{print $3/3600}'

ou

qacct -f /gridware/psmn/accounting -q "*" -o <login> -d 30 | awk '{ SUM += $5} END {print SUM/3600}'
  • Consommation d'heures CPU (utime de date à date, dans cet exemple, l'année 2012) :
qacct -f /gridware/psmn/accounting -b 201201010000 -e 201212312359 -o <login> | tail -1 | awk '{print $3/3600}'

Jobs qui ont des problèmes :

Lancer la commande suivante :

qstat -g c 

et regarder les deux dernières colonnes :

  • aoACD : Nombre de coeurs qui sont au moins dans un des états suivants :
    • a Load threshold alarm
    • o Orphaned
    • A Suspend threshold alarm
    • C Suspended by calendar
    • D Disabled by calendar
  • cdsuE : Nombre de coeurs qui sont au moins dans un des états suivants :
    • c Configuration ambiguous
    • d Disabled
    • s Suspended
    • u Unknown
    • E Error

Possible job status:

  • d(eletion),
  • E(rror),
  • h(old),
  • r(unning),
  • R(estarted),
  • s(uspended),
  • S(uspended),
  • t(ransfering),
  • T(hreshold),
  • w(aiting).

GridEngine : Variables d'environnement

#$ est réservé à GridEngine pour effectuer des transmissions de paramètres (ex: #$ -cwd ou #$ -V).
  • SGE_O_WORKDIR : répertoire d'où à été soumis le job, utilisable dans les scripts
  • NSLOTS : nombre de coeurs demandé
  • JOB_ID : ID du job (unique) assigné par GridEngine
  • JOB_NAME : nom du job (-N)
  • PE_HOSTFILE : fichier de hosts

Références :

en/documentation/tools/sge.1536054966.txt.gz · Dernière modification : 2020/08/25 15:58 (modification externe)