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}'

Troubleshootings:

Run the command:

qstat -g c 

on the output, look at the last two columns:

  • aoACD : Number of cores that are at least in one of the following states:
    • a Load threshold alarm
    • o Orphaned
    • A Suspend threshold alarm * C Suspended by calendar
    • D Disabled by calendar
  • cdsuE : Number of cores that are at least in one of the following states:
    • 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: Environment variables

#$ is dedicated to GridEngine to transmit parametrs (ex: #$ -cwd or #$ -V).
  • SGE_O_WORKDIR : directory where the job was submited, re-usable in scripts
  • NSLOTS : number of slots/cores requested
  • JOB_ID : job id (unique) assigned by GridEngine
  • JOB_NAME : name of the job (-N)
  • PE_HOSTFILE : hosts files (for MPI jobs)

Références :

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