lsb.applications

Sintassi

#INCLUDE "path-to-file"

Descrizione

Inserisce un'impostazione di configurazione da un altro file nell'ubicazione corrente. Utilizzare questa direttiva per dedicare il controllo di una parte della configurazione ad altri utenti o gruppi di utenti fornendo l'accesso in scrittura per il file incluso a specifici utenti o gruppi di utenti e per garantire la congruenza delle impostazioni del file di configurazione in cluster differenti (se si utilizza la funzionalità multicluster LSF).

Per ulteriori informazioni, vedere Contenuto del file di configurazione condiviso.

Predefinito

Non definito.

Sintassi

ABS_RUNLIMIT=y | Y

Descrizione

I limiti e le stime di runtime non sono normalizzati dal fattore CPU host.

Predefinito

Non definito. Limite di esecuzione e stima di runtime normalizzati.

Sintassi

BIND_JOB=NONE | BALANCE | PACK | ANY | USER | USER_CPU_LIST

Descrizione

Se la funzione di collegamento del processore non è configurata con il parametro BIND_JOB in un profilo dell'applicazione in lsb.applications, l' LSF_BIND_JOB impostazione di configurazione lsf.conf diventa effettiva. La configurazione del profilo dell'applicazione per il collegamento del processore sovrascrive la configurazione lsf.conf .

Piattaforme supportate

Linux con kernel versione 2.6 o superiore

Predefinito

Non definito. Il collegamento del processore è disabilitato.

Descrizione

period=period_us

quota=(#tasks + task_delta )*(#cores/MXJ) * scaling_factor * period_us

Una volta configurati, eseguire badmin reconfig o badmin mbdrestart per rendere effettive le modifiche.

Il parametro CGROUP_CPU_LIMIT_USAGE può essere specificato a livello di profilo applicativo e di coda. Se un lavoro ha un limite di utilizzo della CPU di cgroup specificato sia a livello di coda che di applicazione, LSF utilizza il più piccolo dei valori.

Se il parametro CGROUP_CPU_LIMIT_USAGE non è configurato o è configurato con un valore errato, LSF non imposta i valori di cpu.cfs_quota_us e cpu.cfs_period_us (cgroup v1) e cpu.max (cgroup v2). Verranno invece utilizzate le impostazioni predefinite del sistema operativo Linux.

Se viene specificato un valore non supportato, la configurazione verrà ignorata con un messaggio di avvertimento.

Predefinito

Non definito

Descrizione

A partire dal Fix Pack 15, gli amministratori possono usare il parametro CGROUP_CPU_SHARES_FACTOR per specificare una percentuale del valore predefinito per le interfacce cpu.shares e cpu.weight Linux cgroup (v1 o v2), in modo che i lavori che richiedono meno CPU possano ricevere una frazione della quota o del peso della CPU degli altri lavori, invece di ricevere la stessa quota o lo stesso peso della CPU di tutti gli altri lavori in esecuzione. I valori iniziali di cpu.shares e cpu.weight saranno scalati da questo valore di CGROUP_CPU_SHARES_FACTOR , se configurato. Il valore CGROUP_CPU_SHARES_FACTOR può essere specificato a livello di profilo applicativo e di coda. Quando sono definiti più livelli, LSF utilizza il più piccolo dei valori. Per utilizzare il parametro CGROUP_CPU_SHARES_FACTOR , assicurarsi che il parametro LSB_CGROUP_CPU_SHARES_OLD_DEFAULT nel file lsf.conf sia impostato su N o n, oppure lasciarlo indefinito, che è il valore predefinito.

Specificare un numero intero positivo inferiore a 100, poiché questo valore rappresenta una percentuale. Ad esempio, CGROUP_CPU_SHARES_FACTOR=25 indica un fattore di condivisione della CPU pari al 25% dei valori di cpu.shares e cpu.weight.

Predefinito

Non definito

Sintassi

CHKPNT_DIR=dir_chkpn

Descrizione

Specifica la directory di checkpoint per il checkpoint automatico per l'applicazione. Per abilitare il checkpoint automatico per il profilo dell'applicazione, gli amministratori devono specificare una directory del punto di controllo nella configurazione del profilo dell'applicazione.

Se CHKPNT_PERIOD, CHKPNT_INITPERIOD o CHKPNT_METHOD è stato impostato in un profilo applicazione ma CHKPNT_DIR non è stato impostato, viene emesso un messaggio di avvertenza e tali impostazioni vengono ignorate.

La directory del punto di controllo è la directory in cui vengono creati i file del punto di controllo. Specificare un percorso assoluto o un percorso relativo alla directory di lavoro corrente per il lavoro. Non utilizzare le variabili di ambiente nel percorso della directory.

Per abilitare il checkpoint dei lavori con la funzione multicluster LSF, definire una directory di checkpoint in un profilo applicazione (CHKPNT_DIR, CHKPNT_PERIOD, CHKPNT_INITPERIOD, CHKPNT_METHOD in lsb.applications) sia del cluster di inoltro che del cluster di esecuzione. LSF utilizza la directory specificata nel cluster di esecuzione.

Il punto di controllo non è supportato se un lavoro viene eseguito su un host in leasing.

Il percorso file della directory del punto di controllo può contenere fino a 4000 caratteri per UNIX e Linuxo fino a 255 caratteri per Windows, inclusi la directory e il nome file.

Predefinito

Non definito

Sintassi

CHKPNT_INITPERIOD=periodo_init_chkpnt

Descrizione

Specifica il periodo di checkpoint iniziale in minuti. CHKPNT_DIR deve essere impostato nel profilo dell'applicazione per rendere effettivo questo parametro. Il punto di controllo periodico specificato da CHKPNT_PERIOD non si verifica fino a quando non è trascorso il periodo iniziale.

Specificare un intero positivo.

I valori della riga comandi a livello di lavoro sovrascrivono la configurazione del profilo dell'applicazione.

Se gli amministratori specificano un periodo di checkpoint iniziale e non specificano un periodo di checkpoint (CHKPNT_PERIOD), il lavoro eseguirà il checkpoint una sola volta.

Se viene specificato il periodo di checkpoint iniziale di un lavoro e si esegue bchkpnt per eseguire il checkpoint del lavoro in un momento precedente al periodo di checkpoint iniziale, il periodo di checkpoint iniziale non viene modificato da bchkpnt. Il primo punto di controllo automatico si verifica ancora dopo il numero di minuti specificato.

Predefinito

Non definito

Sintassi

CHKPNT_PERIOD=periodi_chkp

Descrizione

Specifica il periodo di checkpoint per l'applicazione in minuti. CHKPNT_DIR deve essere impostato nel profilo dell'applicazione per rendere effettivo questo parametro. Il lavoro in esecuzione viene controllato automaticamente ogni periodo del punto di controllo.

Specificare un intero positivo.

I valori della riga comandi a livello di lavoro sovrascrivono le configurazioni del profilo dell'applicazione e del livello della coda. La configurazione del livello di profilo dell'applicazione sovrascrive la configurazione del livello di coda.

Predefinito

Non definito

Sintassi

CHKPNT_METHOD=metodo_chkp

Descrizione

Specifica il metodo checkpoint. CHKPNT_DIR deve essere impostato nel profilo dell'applicazione per rendere effettivo questo parametro. I valori della riga comandi a livello di lavoro sovrascrivono la configurazione del profilo dell'applicazione.

Predefinito

Non definito

Sintassi

CONTAINER=podman[image(image_name) options(podman_run_options)]

CONTAINER=docker[image(image_name) options(docker_run_options) container_io() job_pre_post()]

CONTAINER=nvidia-docker[image(image_name) options(docker_run_options)]

CONTAINER=shifter[image(image_name) options(container_options)]

CONTAINER=singularity[image(image_name) options(container_options)]

CONTAINER=apptainer[image(image_name) options(apptainer_options]

CONTAINER=enroot[image(image_name) options(enroot_start_options)]

Descrizione

Abilita LSF ad utilizzare un contenitore supportato per i lavori inoltrati a questo profilo applicazione. Questo parametro utilizza le seguenti parole chiave:

podman | docker | nvidia | shifter | singularity | apptainer | enroot

Obbligatorio. Utilizzare una di queste parole chiave per specificare il tipo di contenitore da utilizzare per i lavori inoltrati a questo profilo applicazione.

immagine

Obbligatorio. Questa parola chiave specifica il nome immagine utilizzato nei lavori in esecuzione.

Per i lavori Podman, Docker, NVIDIA Docker ed Enroot, utilizzare la variabile d'ambiente $LSB_CONTAINER_IMAGE per consentire agli utenti di specificare il nome dell'immagine per i lavori del contenitore al momento dell'invio del lavoro. Al momento dell'inoltro del job, gli utenti possono specificare un nome immagine specifico che si trova nel server del repository specificato specificando un valore per la variabile di ambiente $LSB_CONTAINER_IMAGE .

opzioni

Facoltativo. Questa parola chiave specifica le opzioni di esecuzione del lavoro per il contenitore.

Per abilitare l'esecuzione di uno script di pre - esecuzione, specificare un segno di chiocciola (@) e un percorso file completo per lo script, a cui l'host di esecuzione deve poter accedere. Prima dell'esecuzione del lavoro del contenitore, LSF esegue questo script con privilegi di amministratore LSF . Durante l'esecuzione dello script, le variabili di ambiente dei lavori vengono trasmesse allo script. Quando lo script termina l'esecuzione, l'emissione viene utilizzata come opzioni di avvio del contenitore. Lo script deve fornire questo output su una riga. Il metodo di elaborazione del lavoro contenitore dipende dal risultato dello script di pre - esecuzione:

• Se lo script di pre - esecuzione ha esito negativo, il lavoro del contenitore esce con lo stesso codice di uscita dallo script. Inoltre, viene inviato un messaggio di stato esterno per informare l'utente che il lavoro è terminato a causa di un errore di esecuzione dello script.
• Se l'esecuzione dello script ha esito positivo ma l'output contiene più di 512 opzioni, LSF conserva solo le prime 512 opzioni e le restanti vengono ignorate.
• Se l'esecuzione dello script viene eseguita correttamente e l'output è valido, l'output fa parte delle opzioni di esecuzione del lavoro contenitore. La posizione dell'output dallo script nelle opzioni è esattamente dove l'utente ha configurato lo script nel campo delle opzioni.

Per i contenitori Docker e NVIDIA Docker, questa parola chiave specifica le opzioni di esecuzione del lavoro Docker per il comando docker run, che vengono passate al contenitore del lavoro.

Nota:

• Prima di specificare le opzioni di esecuzione del lavoro Docker , assicurarsi che queste opzioni funzionino con il comando docker run nella riga di comando.
• Le opzioni -- cgroup - parent e -- user (o -u) sono riservate per l'utilizzo interno di LSF . Non utilizzare queste opzioni nella configurazione della parola chiave delle opzioni, altrimenti il lavoro non riesce.

  Se hai specificato uno script di pre - esecuzione e l'output di questo script contiene -- cgroup - parent, -- usero -u, anche il lavoro del contenitore non riesce.

• Le opzioni -w e -- ulimit vengono impostate automaticamente per LSF. Non utilizzare queste opzioni nella configurazione della parola chiave delle opzioni perché queste specifiche sovrascrivono le impostazioni LSF .
• L'opzione -v viene automaticamente utilizzata da LSF per montare le directory di lavoro richieste da LSF , ad esempio la directory di lavoro corrente, la directory di spool del lavoro, il file di destinazione per il comando bsub -f , la directory tmp , LSF_TOPe la directory del punto di controllo su richiesta.
• Puoi configurare l'opzione -- rm nella configurazione della parola chiave options per rimuovere automaticamente i contenitori dopo che il lavoro è stato eseguito.
• Puoi abilitare LSF ad assegnare automaticamente un nome a un contenitore Docker quando crea il contenitore Docker . Per abilitare questa funzione, impostare il parametro ENABLE_CONTAINER_NAME su True nel file lsfdockerlib.py .

  Il nome del container utilizza la seguente convenzione di denominazione:

  • Job normali e blaunch contenitori di job paralleli <cluster_name>.job.<job_id>
  • Job array e contenitori di job paralleli blaunch array: <cluster_name>.job.<job_id>.<job_index>
  • blaunch Contenitori di attività di job paralleli <cluster_name>.job.<job_id>.task.<task_id>
  • Contenitori di attività di job paralleli dell'array blaunch <cluster_name>.job.<job_id>.<job_index>.task.<task_id>
• Limitazione: Se utilizzi l'opzione -d , LSF ottiene in modo non corretto lo stato dei lavori Docker comeDONE.

Per i contenitori Shifter, questa parola chiave specifica le opzioni di esecuzione del lavoro Shifter per il comando shifter , che vengono passate al contenitore lavori.

Nota:

• Eseguire shifter --help nella riga comandi per visualizzare le opzioni supportate dal comando shifter .
• Prima di specificare le opzioni di esecuzione del lavoro Shifter, assicurarsi che queste opzioni funzionino con il comando shifter sulla riga comandi.
• La directory $LD_LIBRARY_PATH viene ripulita in base al bit setuid utilizzato da Shifter per funzionare. Di conseguenza, per i programmi che dipendono da $LD_LIBRARY_PATH per funzionare (come openmpi), assicurarsi che il bit setuid possa essere impostato correttamente all'interno del contenitore aggiungendo LD_LIBRARY_PATH alla sezione siteEnvAppend del file udiRoot.conf .

Per i contenitori Singolarità o Apptainer, questa parola chiave specifica le opzioni di esecuzione del lavoro Singolarità o Apptainer per il comando singularity exec o or apptainer exec , che vengono passate al contenitore lavori.

Nota:

• Eseguire singularity exec --help o apptainer exec --help nella riga comandi per visualizzare le opzioni supportate dal comando singularity o apptainer .
• Prima di specificare le opzioni di esecuzione del lavoro Singolarità o Apptainer, assicurarsi che queste opzioni funzionino con il comando singularity exec o apptainer exec nella riga comandi.
• La directory $LD_LIBRARY_PATH viene ripulita in base al bit setuid utilizzato da Singularity o Apptainer. Pertanto, per i programmi che dipendono dal funzionamento di $LD_LIBRARY_PATH (come openmpi), assicurarsi che il bit setuid possa essere impostato correttamente all'interno del contenitore aggiungendo LD_LIBRARY_PATH al file ld.so.conf ed eseguendo il comando ldconfig .

Per i contenitori Podman , questa parola chiave specifica le opzioni di esecuzione del lavoro Podman per il comando podman run , che vengono passate al contenitore lavori.

Nota:

• Prima di specificare le opzioni di esecuzione del job Podman , assicurarsi di utilizzare il comando podman run nella riga comandi.
• L'opzione -- user (o -u) è riservata all'uso interno di LSF . Non utilizzare queste opzioni nella configurazione della parola chiave delle opzioni, altrimenti il lavoro non riesce.

  Se hai specificato uno script di pre - esecuzione e l'output di questo script contiene -- usero -u, anche il lavoro del contenitore ha esito negativo.

• Le opzioni -w e -- ulimit vengono impostate automaticamente per LSF. Non utilizzare queste opzioni nella configurazione della parola chiave delle opzioni perché queste specifiche sovrascrivono le impostazioni LSF .
• L'opzione -v viene automaticamente utilizzata da LSF per montare le directory di lavoro richieste da LSF , ad esempio la directory di lavoro corrente, la directory di spool del lavoro, il file di destinazione per il comando bsub -f , la directory tmp , LSF_TOPe la directory del punto di controllo su richiesta.
• Puoi configurare l'opzione -- rm nella configurazione della parola chiave options per rimuovere automaticamente i contenitori dopo che il lavoro è stato eseguito.
• Limitazione: Se utilizzi l'opzione -d , LSF ottiene in modo non corretto lo stato dei lavori Docker comeDONE.

Per i contenitori Enroot, questa parola chiave specifica le opzioni di esecuzione del lavoro Enroot per il comando enroot start , che vengono passate al contenitore lavori.

Nota: prima di specificare le opzioni di esecuzione del lavoro Enroot, assicurarsi che queste opzioni funzionino con il comando enroot start sulla riga comandi.

container_io()

Facoltativo. A partire dal Fix Pack 15, per i lavori Docker, LSF scrive i file di output nel file system del contenitore Docker. Se impostata, specificare anche la parola chiave job_pre_post().

job_pre_post()

Facoltativo. A partire dal Fix Pack 15, se impostato, per i lavori Docker, consente a LSF di eseguire i comandi pre-esecuzione e post-esecuzione a livello utente all'interno dei container Docker. Se impostata, specificare anche la parola chiave container_io().

Esempi

Begin Application
NAME = podmanapp
CONTAINER = podman[image(repository.example.com:5000/file/path/ubuntu:latest)]
DESCRIPTION = Podman User Service
End Application

Begin Application
NAME = dockerapp
CONTAINER = docker[image(repository.example.com:5000/file/path/ubuntu:latest)
container_io() job_pre_post()]
DESCRIPTION = Docker User Service
End Application

Begin Application
NAME = ndockerapp
CONTAINER = nvidia-docker[image(repository.example.com:5000/file/path/ubuntu:latest)]
DESCRIPTION = NVIDIA Docker User Service
End Application

Begin Application
NAME = shifterapp
CONTAINER = shifter[image(ubuntu:latest)]
DESCRIPTION = Shifter User Service
End Application

Begin Application
NAME = singapp
CONTAINER = singularity[image(/file/path/ubuntu.img)]
DESCRIPTION = Singularity User Service
End Application

Begin Application
NAME = apptainer
CONTAINER = apptainer[image(/share/apptainer/images/ubuntu_latest.sif)]
DESCRIPTION = Apptainer User Service
End Application

Begin Application
NAME = enrootapp
CONTAINER = enroot[image(repository.example.com:5000/file/path/ubuntu:latest)]
DESCRIPTION = Enroot User Service
End Application

Begin Application
NAME = dockerappoptions
CONTAINER = docker[image(repository.example.com:5000/file/path/ubuntu:latest) options(@/share/usr/docker-options.sh)
container_io() job_pre_post()]
DESCRIPTION = Docker User Service with pre-execution script for options
End Application

Begin Application
NAME = ndockerappoptions
CONTAINER = nvidia-docker[image(repository.example.com:5000/file/path/ubuntu:latest) options(@/share/usr/docker-options.sh)]
DESCRIPTION = NVIDIA Docker User Service with pre-execution script for options
End Application

Begin Application
NAME = shifterappoptions
CONTAINER = shifter[image(ubuntu:latest) options(@/share/usr/shifter-options.sh)]
DESCRIPTION = Shifter User Service
End Application

Begin Application
NAME = singappoptions
CONTAINER = singularity[image(/file/path/ubuntu.img) options(@/share/usr/sing-options.sh)]
DESCRIPTION = Singularity User Service
End Application

Begin Application
NAME = apptainer
CONTAINER = apptainer[image(/share/apptainer/images/ubuntu_latest.sif) options(@/share/usr/apptainer-options.sh)]
DESCRIPTION = Apptainer User Service
End Application

Begin Application
NAME = enrootappoptions
CONTAINER = enroot[image(repository.example.com:5000/file/path/ubuntu:latest) options(@/share/usr/enroot-options.sh)]
DESCRIPTION = Enroot User Service with pre-execution script for options
End Application

• Per i lavori sequenziali, specificare il seguente parametro CONTAINER per LSF per rimuovere automaticamente i contenitori dopo che il lavoro è stato eseguito:

  CONTAINER=docker[image(image-name) options(--rm)]

• Per i job paralleli, la rete e IPC devono lavorare tra i contenitori per far funzionare blaunch . Il file di associazione ID utente e nome utente di esecuzione deve essere montato sul contenitore per l'autenticazione blaunch .

  Di conseguenza, specifica il seguente valore di parametro CONTAINER per LSF per configurare l'IPC del contenitore e i parametri di rete in modo che blaunch possa lavorare su più contenitori, configurare il file di password del contenitore per l'autenticazione blaunch e rimuovere automaticamente i contenitori dopo che il lavoro è stato eseguito:

  CONTAINER=docker[image(image-name) options(--rm --network=host --ipc=host -v --runtime=nvidia /path/to/my/passwd:/etc/passwd)]

  Il file passwd deve essere nel formato standard per i file di password UNIX e Linux , come il seguente formato:

  user1:x:10001:10001:::
  user2:x:10002:10002:::

• Per consentire agli utenti di specificare i nomi delle immagini per i lavori dei contenitori Podman, Docker, NVIDIA Docker ed Enroot al momento dell'invio del lavoro, usare la variabile d'ambiente $LSB_CONTAINER_IMAGE come nome dell'immagine quando si specifica la parola chiave image.
  Ad esempio, quando si definisce il parametro CONTAINER per il profilo dell'applicazione udocker , aggiungere la variabile di ambiente $LSB_CONTAINER_IMAGE alla specifica dell'immagine:

  Begin Application
  NAME = udockerGPU
  CONTAINER = docker[image(repository.example.com:5000/$LSB_CONTAINER_IMAGE) \
              options(--rm --net=host --ipc=host -v --runtime=nvidia /gpfs/u/fred:/data )
              container_io() job_pre_post()]
  DESCRIPTION = Docker User Service
  End Application

  Specificare un nome immagine contenitore (come ubuntu) al momento dell'inoltro del lavoro impostando l'ambiente $LSB_CONTAINER_IMAGE utilizzando uno dei seguenti metodi:

  • Specificare la variabile di ambiente $LSB_CONTAINER_IMAGE in base all'ambiente shell:
    • In csh o tcsh:

      setenv LSB_CONTAINER_IMAGE ubuntu

    • In sh, ksho bash:

      export LSB_CONTAINER_IMAGE=ubuntu

  • Utilizzare l'opzione bsub -env :

    bsub -env LSB_CONTAINER_IMAGE=ubuntu -app udocker a.out -in in.dat -out out.dat

  • Utilizza uno script esub per impostare la variabile di ambiente LSB_CONTAINER_IMAGE , quindi richiama esub con il comando bsub .
    Ad esempio, creare uno script esub.docker nella directory $LSF_SERVERDIR con il seguente contenuto:

    #!/bin/sh
    exec 1>&2
    echo "LSB_CONTAINER_IMAGE=∖"$1∖"" >> $LSB_SUB_MODIFY_ENVFILE

    Inoltrare un lavoro per richiamare lo script di esub.docker immettendo il seguente comando:

    bsub -a "docker(ubuntu)" -app udocker a.out -in in.dat -out out.dat

Predefinito

Non definito

Sintassi

CORELIMIT=numero intero

Descrizione

Il limite di dimensione del file core per processo (soft) per tutti i processi appartenenti a un lavoro da questo profilo applicazione (consultare getrlimit(2)). I limiti a livello di applicazione sovrascrivono qualsiasi limite predefinito specificato nella coda, ma devono essere inferiori al limite fisso della coda di inoltro. Il limite principale a livello di lavoro (bsub -C) sovrascrive i limiti a livello di coda e a livello di applicazione.

Per impostazione predefinita, il limite è specificato in KB. Utilizzare LSF_UNIT_FOR_LIMITS in lsf.conf per specificare un'unità più grande per il limite (MB, GB, TB, PB o EB).

Predefinito

Illimitato

Sintassi

Descrizione

Specifica la frequenza CPU per un profilo dell'applicazione. Tutti i lavori inoltrati al profilo dell'applicazione richiedono la frequenza CPU specificata. Il valore è un numero a virgola mobile positivo con unità (GHz, MHz o KHz). Se non è impostata alcuna unità, il valore predefinito è GHz.

Questo valore può essere impostato anche utilizzando il comando bsub –freq.

Il valore di inoltro sovrascriverà il profilo dell'applicazione e il valore del profilo dell'applicazione sovrascriverà il valore di coda.

Predefinito

Non definito (viene utilizzata la frequenza CPU nominale)

Sintassi

CPULIMIT=[[ora:]minuto[/nome_host | /modello_host]

Descrizione

Limita il tempo CPU totale che il lavoro può utilizzare. Questo parametro è utile per impedire i lavori runaway o i lavori che utilizzano troppe risorse.

Quando il tempo CPU totale per l'intero lavoro ha raggiunto il limite, un segnale SIGXCPU viene inviato a tutti i processi che appartengono al lavoro. Se il lavoro non ha un gestore segnali per SIGXCPU, il lavoro viene interrotto immediatamente. Se il segnale SIGXCPU viene gestito, bloccato o ignorato dall'applicazione, dopo la scadenza del periodo di dilazione, LSF invia SIGINT, SIGTERM e SIGKILL al lavoro per eliminarlo.

Se un lavoro genera dinamicamente i processi, il tempo CPU utilizzato da questi processi viene accumulato durante la durata del lavoro.

I processi che esistono per meno di 30 secondi possono essere ignorati.

Per impostazione predefinita, i lavori inoltrati al profilo dell'applicazione senza un limite CPU a livello di lavoro (bsub -c) vengono uccisi quando viene raggiunto il limite CPU. I limiti a livello di applicazione sovrascrivono qualsiasi limite predefinito specificato nella coda.

Il numero di minuti può essere maggiore di 59. Ad esempio, tre ore e mezza possono essere specificate come 3:30 o 210.

Se nessun host o modello host viene fornito con il tempo CPU, LSF utilizza l'host di normalizzazione del tempo CPU predefinito definito a livello di coda (DEFAULT_HOST_SPEC in lsb.queues) se è stato configurato, altrimenti utilizza l'host di normalizzazione del tempo CPU predefinito definito a livello di cluster (DEFAULT_HOST_SPEC in lsb.params) se è stato configurato, altrimenti utilizza l'host con il fattore CPU più elevato (l'host più veloce nel cluster).

Su Windows, un lavoro eseguito sotto un limite di tempo CPU può superare tale limite fino a SBD_SLEEP_TIME. Questo perché sbatchd controlla periodicamente se il limite è stato superato.

Su sistemi UNIX, il limite di CPU può essere applicato dal sistema operativo a livello di processo.

È possibile definire se il limite di CPU è un limite per processo applicato dal sistema operativo o un limite per lavoro applicato da LSF con LSB_JOB_CPULIMIT in lsf.conf.

Predefinito

Illimitato

Sintassi

DATALIMIT=numero intero

Descrizione

Il limite della dimensione del segmento dati per processo (soft) (in KB) per tutti i processi appartenenti a un lavoro in esecuzione nel profilo dell'applicazione (consultare getrlimit(2)).

Per impostazione predefinita, i lavori inoltrati al profilo dell'applicazione senza un limite di dati a livello di lavoro (bsub -D) vengono uccisi quando viene raggiunto il limite di dati. I limiti a livello di applicazione sovrascrivono qualsiasi limite predefinito specificato nella coda, ma devono essere inferiori al limite fisso della coda di inoltro.

Predefinito

Illimitato

Sintassi

DESCRIPTION=testo

Descrizione

Descrizione del profilo dell'applicazione. La descrizione viene visualizzata da bapp -l.

La descrizione deve descrivere chiaramente le funzioni di servizio del profilo applicazione per consentire agli utenti di scegliere il profilo appropriato per ogni lavoro.

Il testo può includere qualsiasi carattere, inclusi gli spazi vuoti. Il testo può essere esteso a più righe terminando la riga precedente con una barra rovesciata (\). La lunghezza massima del testo è 512 caratteri.

Sintassi

DJOB_COMMFAIL_ACTION="KILL_TASKS|IGNORE_COMMFAIL"

Descrizione

Definisce l'azione che LSF deve eseguire se rileva un errore di comunicazione con una o più attività remote parallele o distribuite. Se definito con "KILL_TASKS", LSF tenta di interrompere tutte le attività correnti di un lavoro parallelo o distribuito associato all'errore di comunicazione. Se definito con "IGNORE_COMMFAIL", gli errori verranno ignorati e il lavoro continua. Se non è definito, LSF termina tutte le attività e arresta l'intero lavoro.

Questo parametro si applica solo al framework dell'applicazione distribuita blaunch .

Quando definita in un profilo dell'applicazione, la variabile LSB_DJOB_COMMFAIL_ACTION viene impostata durante l'esecuzione di bsub -app per l'applicazione specificata.

Predefinito

Non definito. Terminare tutte le attività e chiudere l'intero lavoro.

Sintassi

DJOB_DISABLED=Y | N

Descrizione

Disabilita il framework dell'applicazione distribuita blaunch .

Predefinito

Non definito. Il framework dell'applicazione distribuita è abilitato.

Sintassi

DJOB_ENV_SCRIPT=nome_script

Descrizione

Definisce il nome di uno script definito dall'utente per l'impostazione e la ripulitura dell'ambiente di job parallelo o distribuito.

Lo script specificato deve supportare un argomento setup e un argomento di cleanup. Lo script viene eseguito da LSF con l'argomento setup prima di avviare un lavoro parallelo o distribuito e con l'argomento cleanup al termine del lavoro.

Lo script viene eseguito come utente e fa parte del lavoro.

Se viene specificato un percorso completo, LSF utilizza il nome percorso per l'esecuzione. Altrimenti, LSF cerca l'eseguibile da $LSF_BINDIR.

Questo parametro si applica solo al framework dell'applicazione distribuita blaunch .

Quando viene definito in un profilo dell'applicazione, la variabile LSB_DJOB_ENV_SCRIPT viene impostata quando si esegue bsub -app per l'applicazione specificata.

Il percorso del comando può contenere un massimo di 4094 caratteri per UNIX e Linuxo un massimo di 255 caratteri per Windows, inclusi la directory, il nome file e i valori espansi per %J (ID_lavoro) e %I (ID_indice).

Se DJOB_ENV_SCRIPT=openmpi_rankfile.sh è impostata in lsb.applications, LSF crea un file di classificazione host e imposta la variabile di ambiente LSB_RANK_HOSTFILE.

Predefinito

Non definito.

Sintassi

DJOB_HB_INTERVAL=secondi

Descrizione

Valore in secondi utilizzato per calcolare l'intervallo di heartbeat tra l'attività RES e il lavoro RES di un lavoro parallelo o distribuito.

Questo parametro si applica solo al framework dell'applicazione distribuita blaunch .

Quando si specifica DJOB_HB_INTERVAL, l'intervallo viene scalato in base al numero di attività nel lavoro:

max (DJOB_HB_INTERVAL, 10) + fattore_host

Dove

host_factor = 0.01 * il numero di host assegnati per il lavoro

Predefinito

Non definito. Intervallo è il valore predefinito di LSB_DJOB_HB_INTERVAL.

Descrizione

Quando un lavoro ridimensionabile rilascia risorse, il framework del lavoro parallelo distribuito LSF termina le attività in esecuzione se un host è stato completamente rimosso. Un DJOB_RESIZE_GRACE_PERIOD definisce un periodo di tolleranza in secondi per l'applicazione per ripulire le attività stesse prima che LSF le termini forzatamente.

Predefinito

Nessun periodo di tolleranza.

Sintassi

DJOB_RU_INTERVAL=secondi

Descrizione

Valore in secondi utilizzato per calcolare l'intervallo di aggiornamento dell'utilizzo delle risorse per le attività di un lavoro parallelo o distribuito.

Questo parametro si applica solo al framework dell'applicazione distribuita blaunch .

Quando viene specificato DJOB_RU_INTERVAL, l'intervallo viene ridimensionato in base al numero di attività nel job:

max (DJOB_RU_INTERVAL, 10) + fattore_host

Dove

host_factor = 0.01 * il numero di host assegnati per il lavoro

Predefinito

Non definito. Intervallo è il valore predefinito di LSB_DJOB_RU_INTERVAL.

Descrizione

Quando pianifica i lavori inseriti in un contenitore basati su Docker, l'impostazione di questo parametro su y o Y consente a LSF di dare la preferenza agli host di esecuzione che hanno già l'immagine Docker richiesta. Ciò riduce la larghezza di banda della rete e l'orario di inizio del lavoro perché l'host di esecuzione non deve estrarre l'immagine Docker dal repository e il lavoro può iniziare immediatamente sull'host di esecuzione.

Quando questa funzionalità è abilitata, LSF considera le informazioni sull'ubicazione delle immagini Docker quando pianifica i lavori Docker . L'affinità immagine Docker interagisce con la preferenza host e le richieste stringa order[] nel modo seguente:

• Se viene specificata la preferenza host, la preferenza host viene rispettata per prima. Tra gli host con lo stesso livello di preferenza, agli host con l'immagine Docker richiesta viene assegnata una priorità più alta.
• Se viene specificata la stringa order[] , gli host con l'immagine Docker richiesta hanno prima una priorità più alta. Tra gli host che hanno tutti l'immagine Docker richiesta, viene quindi rispettata la stringa order[] .

Il parametro CONTAINER deve essere definito perché questo parametro funzioni con questo profilo applicazione.

Predefinito

Non definito.

Sintassi

ELIGIBLE_PEND_TIME_LIMIT=[ora:]minuto

Descrizione

Specifica il limite di tempo di attesa idoneo per un lavoro.

LSF invia la configurazione del limite di tempo in sospeso idoneo a livello dell'applicazione a IBM Spectrum LSF RTM, che gestisce la segnalazione e le azioni attivate come la notifica utente (ad esempio, la notifica all'utente che ha inoltrato il lavoro e all'amministratore LSF) e le azioni di controllo lavoro (ad esempio, l'interruzione del lavoro). IBM Spectrum LSF RTM confronta il tempo di attesa idoneo del lavoro con il limite di tempo di attesa idoneo e se il lavoro si trova in uno stato di attesa idoneo per un periodo di tempo superiore a quello specificato, IBM Spectrum LSF RTM attiva la segnalazione e le azioni. Questo parametro funziona senza IBM Spectrum LSF RTM, ma LSF non intraprende altre azioni di allarme.

Nel modello di inoltro del lavoro per la funzionalità multicluster LSF, il limite di tempo in sospeso idoneo del lavoro viene ignorato nel cluster di esecuzione, mentre il cluster di inoltro unisce il limite di tempo in sospeso idoneo a livello di coda, applicazione e lavoro in base alle impostazioni locali.

Il limite di tempo in sospeso idoneo è nel formato [ora:]minuto. I minuti possono essere specificati come un numero maggiore di 59. Ad esempio, tre ore e mezza possono essere specificate come 3:30 o 210.

Il limite di tempo in sospeso idoneo al livello del lavoro (bsub -eptl) sovrascrive il limite del livello dell'applicazione specificato qui e il limite del livello dell'applicazione sovrascrive il limite del livello della coda (ELIGIBLE_PEND_TIME_LIMIT in lsb.queues).

Predefinito

Non definito.

Sintassi

ENV_VARS=" name = 'valore' [,name1='value1'] [,name2='value2', ... ] "

Descrizione

ENV_VARS definisce le variabili di ambiente specifiche dell'applicazione che verranno utilizzate dai lavori per l'applicazione. Utilizzare questo parametro per definire coppie nome / valore come variabili di ambiente. Queste variabili di ambiente vengono utilizzate anche nell'ambiente di pre / post - esecuzione.

È possibile includere spazi all'interno delle virgolette singole quando si definisce un valore. Le virgole e le virgolette doppie sono riservate da LSF e non possono essere utilizzate come parte del nome o del valore della variabile di ambiente. Se la stessa variabile di ambiente viene denominata più volte in ENV_VARS e vengono forniti valori differenti, l'ultimo valore nell'elenco sarà quello che ha effetto. LSF non consente alle variabili di ambiente di contenere altre variabili di ambiente da espandere sul versante dell'esecuzione. non ridefinire le variabili di ambiente LSF in ENV_VARS.

Per definire una variabile di ambiente NULL, utilizzare le virgolette singole senza nulla all'interno. Ad esempio:

ENV_VARS="TEST_CAR=''"

Qualsiasi variabile impostata nell'ambiente dell'utente sovrascriverà il valore in ENV_VARS. Il valore del profilo dell'applicazione sovrascriverà il valore dell'ambiente host di esecuzione.

Dopo aver modificato il valore di questo parametro, eseguire badmin reconfig per rendere effettive le modifiche. Le modifiche si applicano solo ai lavori in sospeso. I lavori in esecuzione non vengono influenzati.

Predefinito

Non definito.

Sintassi

ESTIMATED_RUNTIME=[ora:]minuto[/nome_host | /modello_host]

Descrizione

Questo parametro specifica un runtime stimato per i lavori associati ad un'applicazione. LSF utilizza il valore ESTIMATED_RUNTIME solo per scopi di pianificazione e non termina i lavori che superano questo valore a meno che i lavori non superino anche un RUNLIMIT definito. Il formato della stima di runtime è lo stesso del parametro RUNLIMIT.

La stima di tempo di esecuzione a livello di lavoro specificata da bsub -We sovrascrive l'impostazione ESTIMATED_RUNTIME in un profilo applicazione. L'impostazione ESTIMATED_RUNTIME in un profilo dell'applicazione sovrascrive l'impostazione ESTIMATED_RUNTIME nella coda e nel cluster.

Predefinito

Non definito

Sintassi

Lavori Podman : EXEC_DRIVER=context[user(user_name)] starter[/file_path_serverdir/podman-starter.py] controller[/file_path/to/serverdir/podman-control.py] monitor[/file_path/to/serverdir/podman-monitor.py]

Lavori Docker : EXEC_DRIVER=context[user(user_name path(/path/path1:/path/path2)] starter[/file_path_serverdir/docker-starter.py] controller[/file_path/to/serverdir/docker-control.py] monitor[/file_path/to/serverdir/docker-monitor.py]

Sradicamento dei lavori: EXEC_DRIVER=starter[/file_path_serverdir/enroot-starter.py]

Sostituire file_path/to/serverdir con il percorso file effettivo della directory LSF_SERVERDIR .

Descrizione

Facoltativo per i lavori Enroot. Specifica il framework del driver di esecuzione per i lavori del contenitore Podman, Dockero Enroot in questo profilo dell'applicazione. Questo parametro usa la seguente parola chiave:

Utente

facoltativo per i lavori Docker e ignorato per i lavori Enroot. Questa parola chiave specifica l'account utente per avviare gli script. Il valore configurato è un nome utente invece di un ID utente. Per i lavori Docker , questo utente deve essere un membro del gruppo utenti Docker . Per lavori Podman , è necessario impostare il nome utente su "default".

Per impostazione predefinita, questo è l'amministratore principale LSF per impostazione predefinita.

Nota: questo non può essere l'utente root.

LSF include tre script del driver di esecuzione utilizzati per avviare un lavoro (docker-starter.py), monitorare la risorsa di un lavoro (docker-monitor.py) e inviare un segnale a un lavoro (docker-control.py). Questi script si trovano nella directory LSF_SERVERDIR . Modificare il proprietario dei file di script per l'utente di contesto e modificare le autorizzazioni del file su 700 o 500 prima di utilizzarli nel parametro EXEC_DRIVER .

Lo script starter è obbligatorio. Per i lavori del contenitore Docker , gli script di controllo e monitoraggio sono obbligatori se il driver cgroupfs è systemd, ma sono facoltativi se il driver cgroupfs è cgroupfs. Per i lavori contenitore Podman , lo script di monitoraggio è facoltativo mentre lo script di controllo è obbligatorio. Per i lavori del contenitore Enroot, è necessario lo script iniziale mentre tutti gli altri script vengono ignorati.

Interazione con il parametro CONTAINER per i lavori Podman, Dockero Enroot

Per i lavori Podman, Dockero Enroot , il parametro EXEC_DRIVER interagisce con le seguenti parole chiave nel parametro CONTAINER :

• image, che specifica il nome immagine (variabile di ambiente$LSB_CONTAINER_IMAGE ) è supportata quando si specificano nomi script.
• options con opzioni di runtime e lo script di opzioni è supportato.

Esempio

Begin Application
NAME = podmanapp
CONTAINER = podman[image(repository.example.com:5000/file/path/ubuntu:latest) \
            options(--rm --network=host --ipc=host -v /path/to/my/passwd:/etc/passwd)]
EXEC_DRIVER = context[user(default)] starter[/path/to/driver/docker-starter.py] \
              controller[/path/to/driver/podman-control.py] \
              monitor[/path/to/driver/podman-monitor.py]
DESCRIPTION = Podman User Service
End Application

Begin Application
NAME = dockerapp
CONTAINER = docker[image(repository.example.com:5000/file/path/ubuntu:latest) \
            options(--rm --network=host --ipc=host -v /path/to/my/passwd:/etc/passwd)]
EXEC_DRIVER = context[user(user-name) path(/path/one:/path/two)] starter[/path/to/driver/docker-starter.py] \
              controller[/path/to/driver/docker-control.py] \
              monitor[/path/to/driver/docker-monitor.py]
DESCRIPTION = Docker User Service
End Application

Begin Application
NAME = enrootapp
CONTAINER = enroot[image(repository.example.com:5000/file/path/ubuntu:latest) \
            options(--mount /mydir:/mydir2]
EXEC_DRIVER = starter[/path/to/driver/enroot-starter.py]
DESCRIPTION = Enroot User Service
End Application

Predefinito

non definito per i job Podman e Docker .

starter[$LSF_SERVERDIR/enroot-starter.py] per lavori Enroot

Sintassi

FILELIMIT=numero intero

Descrizione

Il limite di dimensione file per processo (soft) (in KB) per tutti i processi appartenenti a un lavoro in esecuzione nel profilo dell'applicazione (vedere getrlimit(2)). I limiti a livello di applicazione sovrascrivono qualsiasi limite predefinito specificato nella coda, ma devono essere inferiori al limite fisso della coda di inoltro.

Predefinito

Illimitato

Descrizione

gvendor=amd nvidia

Specifica il tipo di fornitore GPU. LSF assegna le GPU con il tipo di fornitore specificato.

Specificare amd per richiedere le GPU AMD o specificare nvidia per richiedere le GPU Nvidia.

Per impostazione predefinita, LSF richiede GPU Nvidia.

gmodel=nome_modello[ -dimensione_memoria]

Specifica le GPU con il nome del modello specifico e, facoltativamente, la sua memoria GPU totale. Per impostazione predefinita, LSF assegna le GPU con lo stesso modello, se disponibili.

La parola chiave gmodel supporta i formati seguenti:

gmodel=nome_modello

Richiede le GPU con il marchio e il nome modello specificati (ad esempio, TeslaK80).

gmodel=nome_modello_breve

Richiede GPU con un marchio specifico (ad esempio, Tesla, Quadro, NVS,) o il nome del tipo di modello (ad esempio, K80, P100).

gmodel=nome_modello-dimensione_memoria

Richiede le GPU con il nome del marchio specificato e la dimensione totale della memoria GPU. La dimensione della memoria GPU è composta dal numero e dalla relativa unità, che comprende M, G, T, MB, GBe TB (ad esempio, 12G).

Per trovare i nomi modello GPU disponibili su ciascun host, eseguire i comandi lsload –gpuload, lshosts –gpuo bhosts -gpu . La stringa del nome modello non contiene caratteri spazio. Inoltre, i caratteri barra (/) e trattino (-) vengono sostituiti con il carattere di sottolineatura (_). Ad esempio, il nome del modello GPU "Tesla C2050 / C2070" è convertito in "TeslaC2050_C2070" in LSF.

gmem=valore_memoria

Specificare la memoria GPU su ogni GPU richiesta dal lavoro. Il formato di mem_value è lo stesso di un altro valore di risorsa (ad esempio,memoppureswap) nella sezione rusage dei requisiti della risorsa del lavoro (-R).

gtile=! | num_tili

Specifica il numero di GPU per socket. Specificare un numero per definire esplicitamente il numero di GPU per socket sull'host oppure specificare un punto esclamativo (!) per abilitare LSF al calcolo automatico del numero, che divide equamente le GPU lungo tutti i socket sull'host. LSF garantisce i requisiti gtile anche per i lavori di affinità. Ciò significa che LSF potrebbe non assegnare l'affinità della GPU alle CPU assegnate quando non è possibile soddisfare i requisiti gtile .

Se la parola chiave gtile non viene specificata per un lavoro di affinità, LSF tenta di allocare un numero sufficiente di GPU sui socket che hanno assegnato le GPU. Se non ci sono abbastanza GPU sui socket ottimali, i lavori non possono andare su questo host.

Se la parola chiave gtile non viene specificata per un lavoro non affine, LSF tenta di allocare sufficienti GPU sullo stesso socket. Se non è disponibile, LSF potrebbe allocare le GPU su GPU separate.

nvlink=sì

Obsoleto in LSF, Versione 10.1 Fix Pack 11. Utilizzare invece la parola chiave glink . Abilita l'applicazione del job per connessioni NVLink tra GPU. LSF assegna le GPU con connessioni NVLink in vigore.

glink=sì

Consente l'applicazione dei lavori per connessioni speciali tra GPU. LSF deve allocare le GPU con le connessioni speciali specifiche del fornitore GPU.

Se il lavoro richiede GPU AMD, LSF deve assegnare GPU con la connessione xGMI . Se il lavoro richiede le GPU Nvidia, LSF deve assegnare le GPU con la connessione NVLink.

Non utilizzare glink insieme alla parola chiave nvlink obsoleta.

Per impostazione predefinita, LSF può assegnare GPU senza connessioni speciali quando non ci sono abbastanza GPU con queste connessioni.

mig=GI_size[ /CI_size]

Specifica i requisiti della periferica Nvidia MIG (Multi - Instance GPU).

Specificare la dimensione dell'istanza GPU richiesta per il lavoro MIG. Le dimensioni valide delle istanze GPU sono 1, 2, 3, 4, 7.

Facoltativamente, specificare la dimensione dell'istanza di calcolo richiesta dopo la dimensione dell'istanza GPU specificata e un carattere barra (/). La dimensione dell'istanza di calcolo richiesta deve essere inferiore o uguale alla dimensione dell'istanza della GPU richiesta. Inoltre, Nvidia MIG non supporta le seguenti combinazioni di dimensioni di istanza GPU/calcolo: 4/3, 7/5, 7/6. Se non viene specificato, la dimensione dell'istanza di calcolo predefinita è 1.

Predefinito

Non definito

Vedi anche

Descrizione

Abilita l'elaborazione di post - esecuzione basata sull'host a livello dell'applicazione. Il comando HOST_POST_EXEC viene eseguito su tutti gli host di esecuzione al termine del job. Se la post - esecuzione basata sul lavoro POST_EXEC è stata definita a livello di coda / livello di applicazione / livello di lavoro, il comando HOST_POST_EXEC viene eseguito dopo POST_EXEC di qualsiasi livello.

La regola del comando supportata è la stessa di POST_EXEC esistente per la sezione della coda. Consultare l'argomento POST_EXEC per i dettagli.

Predefinito

Non definito.

Descrizione

Abilita l'elaborazione pre - esecuzione basata sugli host a livello di applicazione. Il comando HOST_PRE_EXEC viene eseguito su tutti gli host di esecuzione prima dell'avvio del lavoro. Se la pre - esecuzione basata sul lavoro PRE_EXEC è stata definita a livello coda / livello applicazione / livello lavoro, il comando HOST_PRE_EXEC viene eseguito prima di PRE_EXEC di qualsiasi livello.

La regola del comando supportata è la stessa di PRE_EXEC esistente per la sezione della coda. Consultare l'argomento PRE_EXEC per i dettagli.

Predefinito

Non definito.

Sintassi

JOB_CWD=elenco

Descrizione

La directory di lavoro corrente (CWD) per il lavoro nel profilo applicazione. Il percorso può essere assoluto o relativo alla directory di inoltro. Il percorso può includere i seguenti modelli dinamici (che sono sensibili al maiuscolo / minuscolo):

I pattern non supportati vengono trattati come testo.

Se questo parametro viene modificato, qualsiasi lavoro appena inoltrato con l'opzione -app utilizzerà il nuovo valore per CWD se bsub -cwd non è definito.

JOB_CWD supporta tutte le convenzioni di percorso LSF come i formati UNIX, UNC e Windows. Nel cluster UNIX /Windows misto, può essere specificato con un valore per UNIX e un altro valore per Windows separato da un carattere pipe (|).

JOB_CWD=unix_path|windows_path

La prima parte del percorso deve essere per UNIX e la seconda parte per Windows. Entrambi i percorsi devono essere percorsi completi.

Predefinito

Non definito.

Sintassi

JOB_CWD_TTL=ore

Descrizione

Specifica il TTL (time - to - live) per la directory di lavoro corrente (CWD) di un lavoro. LSF cancella le directory CWD create dopo che un lavoro è terminato in base al valore TTL. LSF elimina il CWD per il lavoro se LSF ha creato tale directory per il lavoro. Sono disponibili le seguenti opzioni:

Il sistema controlla l'elenco di directory ogni 5 minuti per quanto riguarda la ripulitura e cancella solo l'ultima directory del percorso per evitare conflitti quando più lavori condividono alcune directory principali. TTL verrà calcolato una volta terminato lo script post - exec. Quando LSF (sbatchd) viene avviato, controlla il file di elenco directory ed elimina i CWD scaduti.

Se il valore per questo parametro non è impostato nel profilo dell'applicazione, LSF verifica se è impostato a livello di cluster. Se nessuno dei due è impostato, viene utilizzato il valore predefinito.

Predefinito

Non definito. Viene utilizzato il valore 2147483647, che indica che CWD non viene eliminato.

Descrizione

La variabile LSB_JOB_INCLUDE_POST - proc nell'ambiente utente sovrascrive il valore di JOB_INCLUDE_POSTPROC in un profilo applicazione in lsb.applications. JOB_INCLUDE_POSTPROC in un profilo applicazione in lsb.applications sostituisce il valore di JOB_INCLUDE_POSTPROC in lsb.params.

Per i lavori di affinità CPU e memoria, se JOB_INCLUDE_POSTPROC=Y, LSF non rilascia le risorse di affinità fino al termine dell'elaborazione di post - esecuzione, poiché gli slot sono ancora occupati dal lavoro durante l'elaborazione di post - esecuzione.

Per i cpuset SGI, se JOB_INCLUDE_POSTPROC=Y, LSF non rilascia il cpuset fino al termine dell'elaborazione di post - esecuzione, anche se i processi di post - esecuzione non sono collegati al cpuset.

Predefinito

N. L'elaborazione di post - esecuzione non è inclusa come parte del lavoro e un nuovo lavoro può essere avviato sull'host di esecuzione prima che termini l'elaborazione di post - esecuzione.

Descrizione

Specifica un timeout in minuti per l'elaborazione di post - esecuzione del lavoro. Il timeout specificato deve essere maggiore di zero

Se l'elaborazione di post - esecuzione impiega più tempo del timeout, sbatchd riporta che la post - esecuzione non è riuscita (stato POST_ERR). Su UNIX e Linux, termina l'intero gruppo di processo dei processi di preesecuzione del lavoro. In Windows, solo il processo principale del comando di pre - esecuzione viene interrotto quando scade il timeout, i processi secondari del comando di pre - esecuzione non vengono terminati.

Se JOB_INCLUDE_POSTPROC=Ye sbatchd interrompe i processi di post - esecuzione perché è stato raggiunto il timeout, il tempo CPU dell'elaborazione di post - esecuzione è impostato su 0 e il tempo CPU del lavoro non include il tempo CPU dell'elaborazione di post - esecuzione.

JOB_POSTPROC_TIMEOUT definito in un profilo applicazione in lsb.applications sovrascrive il valore in lsb.params. JOB_POSTPROC_TIMEOUT non può essere definito nell'ambiente utente.

Quando si esegue l'elaborazione post - esecuzione basata sull'host, impostare JOB_POSTPROC_TIMEOUT su un valore che fornisca al processo tempo sufficiente per l'esecuzione.

Predefinito

Non definito. L'elaborazione di post - esecuzione non va in timeout.

Descrizione

Specificare un valore di timeout in minuti per l'elaborazione di pre - esecuzione del lavoro. Il timeout specificato deve essere un numero intero maggiore di zero. Se l'elaborazione di pre - esecuzione del lavoro richiede più tempo del timeout, LSF termina i processi di preesecuzione del lavoro, termina il lavoro con un valore di uscita predefinito di 98 e quindi riaccoda il lavoro all'intestazione della coda. Tuttavia, se il numero di tentativi di pre - esecuzione ha raggiunto la soglia dei tentativi di pre - esecuzione, LSF sospende il lavoro con stato PSUSP invece di riaccodare.

JOB_PREPROC_TIMEOUT definito in un profilo applicazione in lsb.applications sovrascrive il valore in lsb.params. JOB_PREPROC_TIMEOUT non può essere definito nell'ambiente utente.

Su UNIX e Linux, sbatchd termina l'intero gruppo di processo dei processi di preesecuzione del lavoro.

In Windows, solo il processo principale del comando di pre - esecuzione viene interrotto quando scade il timeout, i processi secondari del comando di pre - esecuzione non vengono terminati.

Predefinito

Non definito. L'elaborazione di pre - esecuzione non va in timeout. Tuttavia, quando si esegue l'elaborazione di pre - esecuzione basata sull'host, non è possibile utilizzare il valore infinito o avrà esito negativo. È necessario configurare un valore ragionevole.

Sintassi

JOB_SIZE_LIST=dimensione_predefinita [dimensione ...]

Descrizione

Un elenco di dimensioni lavoro (numero di attività) consentite su questa applicazione.

Quando si inoltra un lavoro o si modifica un lavoro in sospeso che richiede una dimensione del lavoro utilizzando le opzioni -n o -R per bsub e bmod, la dimensione del lavoro richiesto deve essere un singolo valore fisso che corrisponde a uno dei valori specificati da JOB_SIZE_LIST , che sono le dimensioni del lavoro consentite su questo profilo dell'applicazione. LSF rifiuta il lavoro se la dimensione del lavoro richiesto non è presente in questo elenco. Inoltre, quando si utilizza bswitch per commutare un lavoro in sospeso con una dimensione lavoro richiesta in un'altra coda, anche la dimensione lavoro richiesta nel lavoro in sospeso deve corrispondere a uno dei valori in JOB_SIZE_LIST per la nuova coda.

Il primo valore in questo elenco è la dimensione lavoro predefinita, che è la richiesta di dimensione lavoro assegnata se il lavoro è stato inoltrato senza richiederlo. I restanti valori sono le altre dimensioni di lavoro consentite nella coda e possono essere definiti in qualsiasi ordine.

Quando viene definita sia in una coda (lsb.queues) che in un profilo applicazione, la richiesta di dimensione lavoro deve soddisfare entrambi i requisiti. Inoltre, JOB_SIZE_LIST sovrascrive qualsiasi parametro TASKLIMIT definito allo stesso livello. I requisiti di dimensione del lavoro non si applicano alle code e ai profili dell'applicazione senza elenchi di dimensione del lavoro, né ad altri livelli di inoltro del lavoro (ovvero, a livello host o a livello cluster).

Valori validi

Un elenco separato da spazi di numeri interi positivi tra 1 e 2147483646.

Predefinito

Non definito

Sintassi

JOB_STARTER=starter [starter ] ["%USRCMD"] [starter ]

Descrizione

Crea un ambiente specifico per i lavori inoltrati prima dell'esecuzione. Uno starter lavoro a livello di applicazione sovrascrive uno starter lavoro a livello di coda.

starter è qualsiasi eseguibile che può essere utilizzato per avviare il lavoro (ad esempio, può accettare il lavoro come un argomento di input). Facoltativamente, è possibile specificare ulteriori stringhe.

Per impostazione predefinita, i comandi utente vengono eseguiti dopo lo starter del lavoro. Una stringa speciale, %USRCMD, può essere utilizzata per rappresentare la posizione del lavoro dell'utente nella riga comandi del programma di avvio lavoro. La stringa %USRCMD e i comandi aggiuntivi devono essere racchiusi tra virgolette (" ").

Esempio

JOB_STARTER=csh -c "%USRCMD;sleep 10"

bsub myjob arguments

csh -c "myjob arguments;sleep 10"

Predefinito

Non definito. Non viene utilizzato alcun starter di lavoro,

Sintassi

LOCAL_MAX_PREEXEC_RETRY=numero intero

Descrizione

Il numero massimo di tentativi di esecuzione del comando di pre - esecuzione di un lavoro sul cluster locale.

Quando viene raggiunto questo limite, il comportamento predefinito del lavoro viene definito dal parametro LOCAL_MAX_PREEXEC_RETRY_ACTION in lsb.params, lsb.queueso lsb.applications.

Valori validi

0 < MAX_PREEXEC_RETRY < INFINIT_INT

INFINIT_INT è definito in lsf.h.

Predefinito

Non definito. Il numero di tentativi di preesecuzione è illimitato

Vedi anche

LOCAL_MAX_PREEXEC_RETRY_ACTION in lsb.params, lsb.queuese lsb.applications.

Sintassi

LOCAL_MAX_PREEXEC_RETRY_ACTION=SUSPEND | EXIT

Descrizione

Il comportamento predefinito di un lavoro quando raggiunge il numero massimo di volte per tentare il comando di pre - esecuzione sul cluster locale (LOCAL_MAX_PREEXEC_RETRY in lsb.params, lsb.queueso lsb.applications).

• Se impostato su SUSPEND, il lavoro è sospeso e il relativo stato è impostato su PSUSP.
• Se è impostato su EXIT, il lavoro esce e il suo stato è impostato su EXIT. Il lavoro termina con lo stesso codice di uscita dell'ultimo codice di uscita di errore pre - esecuzione.

Questo parametro è configurato a livello di cluster (lsb.params), a livello della coda (lsb.queues) e a livello dell'applicazione (lsb.applications). L'azione specificata in lsb.applications sovrascrive lsb.queuese lsb.queues sovrascrive la configurazione lsb.params .

Predefinito

Non definito. Se non definito in lsb.queues o lsb.params, l'azione predefinita è SUSPEND.

Vedi anche

LOCAL_MAX_PREEXEC_RETRY in lsb.params, lsb.queuese lsb.applications.

Sintassi

MAX_JOB_PREEMPT=numero intero

Descrizione

Il numero massimo di volte in cui è possibile anticipare un lavoro. Si applica solo alla precedenza basata sulla coda.

Valori validi

0 < MAX_JOB_PREEMPT < INFINIT_INT

INFINIT_INT è definito in lsf.h.

Predefinito

Non definito. Il numero di volte di prelazione è illimitato.

Sintassi

MAX_JOB_REQUEUE=numero intero

Descrizione

Il numero massimo di volte per riaccodare un lavoro automaticamente.

Valori validi

0 < MAX_JOB_REQUEUE < INFINIT_INT

INFINIT_INT è definito in lsf.h.

Predefinito

Non definito. Il numero di riaccodamenti è illimitato

Sintassi

MAX_PREEXEC_RETRY=numero intero

Descrizione

Utilizzare REMOTE_MAX_PREEXEC_RETRY. Questo parametro viene mantenuto solo per la compatibilità con le versioni precedenti.

Modello di inoltro lavori solo per la funzionalità multicluster LSF . Il numero massimo di volte in cui tentare il comando di pre - esecuzione di un lavoro da un cluster remoto.

Se il comando di pre - esecuzione del lavoro ha esito negativo per tutti i tentativi, il lavoro viene restituito al cluster di inoltro.

Valori validi

0 < MAX_PREEXEC_RETRY < INFINIT_INT

INFINIT_INT è definito in lsf.h.

Predefinito

5

Sintassi

MAX_TOTAL_TIME_PREEMPT=numero intero

Descrizione

Il tempo di prelazione accumulato, in minuti, dopo il quale un lavoro non può essere nuovamente prelato, dove minuti è l'ora dell'orologio a muro, non l'ora normalizzata.

L'impostazione di questo parametro in lsb.applications sovrascrive il parametro con lo stesso nome in lsb.queues e in lsb.params.

Valori validi

Qualsiasi numero intero positivo maggiore o uguale a uno (1)

Predefinito

Illimitato

Sintassi

MEMLIMIT=numero intero

Descrizione

Il limite della dimensione della serie residente del processo per processo (soft) per tutti i processi appartenenti a un lavoro in esecuzione nel profilo dell'applicazione.

Imposta la quantità massima di memoria fisica (dimensione serie residente, RSS) che può essere assegnata a un processo.

Per impostazione predefinita, il limite è specificato in KB. Utilizzare LSF_UNIT_FOR_LIMITS in lsf.conf per specificare un'unità più grande per il limite (MB, GB, TB, PB o EB).

Per impostazione predefinita, i lavori inoltrati al profilo applicazione senza un limite di memoria a livello di lavoro vengono uccisi quando viene raggiunto il limite di memoria. I limiti a livello di applicazione sovrascrivono qualsiasi limite predefinito specificato nella coda, ma devono essere inferiori al limite fisso della coda di inoltro.

Applicazione limite memoria SO

L'applicazione del limite di memoria del sistema operativo è il comportamento MEMLIMIT predefinito e non richiede ulteriore configurazione. L'applicazione del sistema operativo di norma consente al processo di essere eventualmente eseguito fino al completamento. LSF passa MEMLIMIT al sistema operativo, che lo usa come guida per lo scheduler del sistema e l'allocatore di memoria. Il sistema può allocare più memoria ad un processo se c'è un surplus. Quando la memoria è scarsa, il sistema acquisisce memoria e riduce la priorità di pianificazione (riassegnazione) di un processo che ha superato il MEMLIMIT dichiarato. Disponibile solo su sistemi che supportano RLIMIT_RSS per setrlimit().

Applicazione del limite di memoria LSF

Per abilitare l'applicazione del limite di memoria LSF, impostare LSB_MEMLIMIT_ENFORCEMENT in lsf.conf suy. l'applicazione del limite di memoria LSF invia esplicitamente un segnale per interrompere un processo in esecuzione una volta assegnata la memoria oltre MEMLIMIT.

È anche possibile abilitare l'applicazione del limite di memoria LSF impostando LSB_JOB_MEMLIMIT in lsf.conf suy. La differenza tra LSB_JOB_MEMLIMIT impostato su y e LSB_MEMLIMIT_ENFORCE impostato su y è che con LSB_JOB_MEMLIMIT, è abilitato solo il limite di memoria per lavoro applicato da LSF. Il limite di memoria per processo applicato dal SO è disabilitato. Con LSB_MEMLIMIT_ENFORCE impostato su y, vengono abilitati sia il limite di memoria per lavoro applicato da LSF che il limite di memoria per processo applicato dal sistema operativo.

Disponibile per tutti i sistemi su cui LSF raccoglie l'utilizzo totale della memoria.

Predefinito

Illimitato

Descrizione

Un limite di memoria è la quantità massima di memoria che un lavoro può utilizzare. I lavori che superano il livello vengono uccisi. È possibile specificare diversi tipi di limiti di memoria da applicare. Utilizzare qualsiasi combinazione di JOB, PROCESS e TASK.

Specificando un valore nel profilo dell'applicazione, si sovrascrivono i seguenti tre parametri: LSB_JOB_MEMLIMIT, LSB_MEMLIMIT_ENFORCE, LSF_HPC_EXTENSIONS (TASK_MEMLIMIT).

Predefinito

Non definito. Il livello di limite di memoria è ancora controllato da LSF_HPC_EXTENSIONS = TASK_MEMLIMIT, LSB_JOB_MEMLIMIT, LSB_MEMLIMIT_ENFORCE

Sintassi

MIG=minuti

Descrizione

Abilita la migrazione automatica del lavoro e specifica la soglia di migrazione per i lavori sottoponibili a checkpoint o rieseguibili, in minuti.

LSF migra automaticamente i lavori che sono stati nello stato SSUSP per un numero di minuti superiore a quello specificato. Il valore 0 specifica che un lavoro sospeso viene migrato immediatamente. La soglia di migrazione si applica a tutti i lavori in esecuzione sull'host.

La soglia di trasferimento della riga comandi a livello di lavoro sovrascrive la configurazione della soglia nella coda e nel profilo dell'applicazione. La configurazione del profilo dell'applicazione sovrascrive la configurazione del livello coda.

Quando viene specificata una soglia di migrazione host ed è inferiore al valore del lavoro, della coda o dell'applicazione, viene utilizzato il valore host.

I membri di un lavoro di porzione possono essere migrati. I lavori di porzione in stato WAIT vengono rimossi dalla porzione di lavoro e messi in stato PEND.

Non influisce sui lavori inoltrati a un cluster remoto.

Predefinito

Non definito. LSF non migra automaticamente i lavori sottoponibili a checkpoint o rieseguibili.

Sintassi

NAME=stringa

Descrizione

Obbligatorio. Nome univoco per il profilo applicazione.

Specificare qualsiasi stringa ASCII con una lunghezza massima di 60 caratteri. È possibile utilizzare lettere, cifre, caratteri di sottolineatura (_), trattini (-), punti (.) o spazi nel nome. Il nome del profilo applicazione deve essere univoco all'interno del cluster.

NAME=myapp 1.0

Predefinito

È necessario specificare questo parametro per definire un profilo applicazione. LSF non assegna automaticamente un nome profilo applicazione predefinito.

Sintassi

NICE=numero intero

Descrizione

Regola la priorità di pianificazione UNIX con cui vengono eseguiti i lavori dell'applicazione.

Un valore 0 (zero) mantiene la priorità di pianificazione predefinita per i lavori interattivi UNIX. Questo valore regola le priorità di runtime per i lavori batch per controllarne l'effetto su altri lavori batch o interattivi. Fare riferimento allenice(1) pagina manuale per maggiori dettagli.

LSF su Windows non supportaHIGHoppureREAL-TIMEclassi di priorità.

Quando è impostato, questo valore sovrascrive NICE impostato a livello di coda in lsb.queues.

Predefinito

Non definito.

Descrizione

Il parametro NO_PREEMPT_INTERVAL=0 consente la prelazione immediata dei lavori non appena vengono avviati o ripresi in esecuzione.

L'impostazione di questo parametro in lsb.applications sovrascrive il parametro con lo stesso nome nei file lsb.queues e lsb.params .

Predefinito

0

Descrizione

Impedisce la prelazione dei lavori che termineranno entro il numero di minuti specificato o la percentuale specificata del tempo di esecuzione stimato o del limite di esecuzione.

Specifica che i lavori che terminano entro il numero specificato di minuti o la percentuale della durata del lavoro non devono essere anticipati, dove minuti è l'ora dell'orologio a muro, non l'ora normalizzata. La percentuale deve essere maggiore di 0 o minore di 100% (tra 1% e 99%).

Ad esempio, se il limite di esecuzione del lavoro è 60 minuti e NO_PREEMPT_FINISH_TIME=10%, il lavoro non può essere preceduto dopo essere stato eseguito per 54 minuti o più.

Se si specifica una percentuale per NO_PREEMPT_FINISH_TIME, è necessario un runtime (bsub -We o ESTIMED_RUNTIME in lsb.applications) o un limite di esecuzione da specificare per il lavoro (bsub -W, o RUNLIMIT in lsb.queueso RUNLIMIT in lsb.applications)

Descrizione

Impedisce la precedenza dei lavori che sono stati in esecuzione per il numero di minuti specificato o la percentuale specificata del tempo di esecuzione stimato o del limite di esecuzione.

Specifica che i lavori che sono stati in esecuzione per il numero specificato di minuti o più non devono essere anticipati, dove minuti è l'ora dell'orologio a muro, non l'ora normalizzata. La percentuale deve essere maggiore di 0 o minore di 100% (tra 1% e 99%).

Ad esempio, se il limite di esecuzione del job è 60 minuti e NO_PREEMPT_RUN_TIME=50%, il job non può essere preceduto dopo essere stato eseguito per 30 minuti o più.

Se si specifica una percentuale per NO_PREEMPT_RUN_TIME, è necessario un runtime (bsub -We o ESTIMATED_RUNTIME in lsb.applications) o un limite di esecuzione da specificare per il lavoro (bsub -W, o RUNLIMIT in lsb.queueso RUNLIMIT in lsb.applications)

Sintassi

PEND_TIME_LIMIT=[ora:]minuto

Descrizione

Specifica il limite di tempo in sospeso per un lavoro.

LSF invia la configurazione del limite di tempo in sospeso a livello dell'applicazione a IBM Spectrum LSF RTM, che gestisce la segnalazione e le azioni attivate come la notifica utente (ad esempio, la notifica all'utente che ha inoltrato il lavoro e all'amministratore LSF) e le azioni di controllo lavoro (ad esempio, l'interruzione del lavoro). IBM Spectrum LSF RTM confronta il tempo di attesa del lavoro con il limite di tempo in sospeso e se il lavoro è in sospeso per un periodo superiore a questo limite di tempo specificato, IBM Spectrum LSF RTM attiva la segnalazione e le azioni. Questo parametro funziona senza IBM Spectrum LSF RTM, ma LSF non intraprende altre azioni di allarme.

Nel modello di inoltro del lavoro per la funzionalità multicluster LSF, il limite di tempo in sospeso del lavoro viene ignorato nel cluster di esecuzione, mentre il cluster di inoltro unisce il limite di tempo in sospeso a livello di coda, applicazione e lavoro in base alle impostazioni locali.

Il limite di tempo in sospeso è nel formato [ora:]minuto. I minuti possono essere specificati come un numero maggiore di 59. Ad esempio, tre ore e mezza possono essere specificate come 3:30 o 210.

Il limite di tempo in sospeso a livello di lavoro (bsub -ptl) sovrascrive il limite di livello dell'applicazione qui specificato e il limite di livello dell'applicazione sovrascrive il limite di livello della coda (PEND_TIME_LIMIT in lsb.queues).

Predefinito

Non definito.

Descrizione

Si applica durante la migrazione di job paralleli nella funzionalità multicluster LSF. L'impostazione PERSISTENT_HOST_ORDER=Y garantisce che i lavori vengano riavviati sugli host in base a nomi alfabetici degli host, impedendo loro di essere riavviati sugli stessi host su cui sono stati eseguiti prima della migrazione.

Predefinito

PERSISTENT_HOST_ORDER=N. I lavori migrati in Capacità multicluster LSF possono essere eseguiti sugli stessi host su cui sono stati eseguiti prima.

Sintassi

PLAN = Y | N | "<key>[value] ..."

Descrizione

LSF richiede che il parametro ALLOCATION_PLANNER sia abilitato per utilizzare PLAN=Y.

Definito anche a livello di cluster e di coda. La precedenza è: applicazione, coda, globale. Ad esempio, l'impostazione del livello dell'applicazione sovrascrive l'impostazione del livello della coda.

Sono supportate le seguenti coppie chiave - valore:

Predefinito

N

Descrizione

Abilita l'elaborazione di post - esecuzione a livello di applicazione. Il comando POST_EXEC viene eseguito sull'host di esecuzione una volta terminato il lavoro. I comandi di post - esecuzione possono essere configurati a livello di lavoro, applicazione e coda.

Se vengono specificati sia i comandi di post - esecuzione a livello di applicazione (POST_EXEC in lsb.applications) che a livello di lavoro, la post - esecuzione a livello di lavoro sovrascrive i comandi di post - esecuzione a livello di applicazione. I comandi di post - esecuzione a livello di coda (POST_EXEC in lsb.queues) vengono eseguiti dopo i comandi di post - esecuzione a livello di applicazione e post - esecuzione a livello di lavoro.

Il comando POST_EXEC utilizza gli stessi valori della variabile di ambiente del lavoro e viene eseguito con l'account dell'utente che inoltra il lavoro.

Quando un lavoro esce con uno dei REQUEUE_EXIT_VALUESdel profilo applicazione, LSF riaccoda il lavoro e imposta la variabile di ambiente LSB_JOBPEND. Il comando di post - esecuzione viene eseguito al termine del lavoro riaccodato.

Quando si esegue il comando di post - esecuzione, la variabile di ambiente LSB_JOBEXIT_STAT viene impostata sullo stato di uscita del lavoro. Se l'ambiente di esecuzione del lavoro non può essere impostato, LSB_JOBEXIT_STAT è impostato su 0 (zero).

Il percorso del comando può contenere fino a 4094 caratteri per UNIX e Linuxo fino a 255 caratteri per Windows, inclusi la directory, il nome file e i valori espansi per %J (ID_lavoro) e %I (ID_indice).

Predefinito

Non definito. Nessun comando di post - esecuzione è associato al profilo dell'applicazione.

Descrizione

I lavori preventivi attenderanno il numero di secondi specificato dall'ora di inoltro prima di anticipare eventuali lavori preventivabili a bassa priorità. Durante il periodo di tolleranza, la prelazione non verrà eseguita, ma il lavoro può essere pianificato e distribuito da altre politiche di pianificazione.

Questa funzione può fornire flessibilità per ottimizzare il sistema per ridurre il numero di prelazioni. È utile per ottenere prestazioni migliori e velocità di trasmissione dei lavori. Quando i lavori a bassa priorità sono brevi, se i lavori ad alta priorità possono attendere il completamento dei lavori a bassa priorità, è possibile evitare la prelazione e migliorare le prestazioni del cluster. Se il lavoro è ancora in sospeso dopo la scadenza del periodo di dilazione, la prelazione verrà attivata.

Il tempo di attesa è solo per i lavori preventivi nello stato in sospeso. Non influirà sui lavori preventivi sospesi.

L'ora viene conteggiata dall'ora di inoltro dei lavori. L'ora di inoltro indica l'ora in cui mbatchd accetta un lavoro, che include i lavori appena inoltrati, i lavori riavviati (da brestart) o i lavori inoltrati da un cluster remoto.

Quando il lavoro preventivo è in attesa, il motivo in sospeso è:

Il lavoro di prelazione consente un periodo di tolleranza prima della prelazione.

Se si utilizza una versione precedente di bjobs, il motivo in sospeso è:

Codice di errore sconosciuto < 6701>;

Il parametro è definito in lsb.params, lsb.queues (sovrascrive lsb.params) e lsb.applications (sovrascrive sia lsb.params che lsb.queues).

Eseguire badmin reconfig per rendere effettive le modifiche.

Predefinito

Non definito (se il parametro non è definito da nessuna parte, la precedenza è immediata).

Descrizione

Abilita l'elaborazione di pre - esecuzione a livello di applicazione. Il comando PRE_EXEC viene eseguito sull'host di esecuzione prima dell'avvio del lavoro. Se il comando PRE_EXEC termina con un codice di uscita diverso da zero, LSF rimette il lavoro all'inizio della coda.

Il comando PRE_EXEC utilizza gli stessi valori della variabile di ambiente del lavoro e viene eseguito con l'account dell'utente che inoltra il lavoro.

Il percorso del comando può contenere fino a 4094 caratteri per UNIX e Linuxo fino a 255 caratteri per Windows, inclusi la directory, il nome file e i valori espansi per %J (ID_lavoro) e %I (ID_indice).

Predefinito

Non definito. Nessun comando di pre - esecuzione è associato al profilo dell'applicazione.

Sintassi

PROCESSLIMIT=numero intero

Descrizione

Limita il numero di processi simultanei che possono essere parte di un lavoro.

Per impostazione predefinita, i lavori inoltrati al profilo dell'applicazione senza un limite di elaborazione a livello di lavoro vengono uccisi quando viene raggiunto il limite di elaborazione. I limiti a livello di applicazione sovrascrivono qualsiasi limite predefinito specificato nella coda.

SIGINT, SIGTERM e SIGKILL vengono inviati al lavoro in sequenza quando viene raggiunto il limite.

Predefinito

Illimitato

Sintassi

PRIORITY =numero intero

Descrizione

Specifica una priorità che viene utilizzata come fattore quando si calcola la priorità del lavoro per APS (absolute job priority scheduling).

Valori validi

Specificare un numero intero compreso tra 0 e 2147483646.

Predefinito

Non definito.

Se APS è abilitato per utenti, gruppi di utenti o profili applicazione, il valore predefinito è 0.

Descrizione

Quando un lavoro viene inoltrato a un profilo dell'applicazione con il parametro RC_ACCOUNT specificato, gli host presi in prestito per eseguire il lavoro vengono contrassegnati con il valore del parametro RC_ACCOUNT . L'host preso in prestito non può essere utilizzato da altre applicazioni che hanno un valore diverso per il parametro RC_ACCOUNT (o che non hanno il parametro RC_ACCOUNT definito).

Dopo che l'host preso in prestito si unisce al cluster, utilizzare il comando lshosts -s per visualizzare il valore del parametro RC_ACCOUNT per l'host.

Esempio

RC_ACCOUNT=project1

Predefinito

Nessun account definito per il profilo applicazione

Sintassi

RC_RECLAIM_ACTION = REQUEUE | TERMINATE

Descrizione

Specificare una delle seguenti azioni:

• REQUEUE: riaccodare i lavori in esecuzione su un host recuperato.
• TERMINATE: terminare i lavori in esecuzione su un host recuperato.

Predefinito

TERMINATE per lavori interattivi.

REQUEUE per tutti gli altri lavori.

Sintassi

REMOTE_MAX_PREEXEC_RETRY=numero intero

Descrizione

Modello di inoltro lavori solo per la funzionalità multicluster LSF . Il numero massimo di volte in cui tentare il comando di pre - esecuzione di un lavoro da un cluster remoto.

Se il comando di pre - esecuzione del lavoro ha esito negativo per tutti i tentativi, il lavoro viene restituito al cluster di inoltro.

Valori validi

fino a INFINIT_INT definito in lsf.h.

Predefinito

5

Sintassi

REQUEUE_EXIT_VALUES=[codice_uscita ...] [EXCLUDE(codice_uscita ...)]

Descrizione

Abilita la riaccodamento automatico del lavoro e imposta la variabile di ambiente LSB_EXIT_REQUEUE. Utilizzare spazi per separare più codici di uscita. I valori di uscita a livello di applicazione sovrascrivono i valori a livello di coda. I valori di uscita a livello di lavoro (bsub -Q) sovrascrivono i valori a livello di applicazione e di coda.

"[all] [~number ...] | [number ...]"

La parola chiave riservata all specifica tutti i codici di uscita. I codici di uscita sono generalmente compresi tra 0 e 255. Utilizzare una tilde (~) per escludere i codici di uscita specificati dall'elenco.

I lavori vengono riaccodati all'intestazione della coda. L'output dell'esecuzione non riuscita non viene salvato e l'utente non viene notificato da LSF.

Definire un codice di uscita come EXCLUDE (exit_code) per abilitare la riaccodamento del lavoro esclusivo, assicurando che il lavoro non venga rieseguito sullo stesso host. La riaccodamento del job esclusivo non funziona per i job paralleli.

Per i lavori con la funzionalità multicluster LSF inoltrata a un cluster di esecuzione remoto, i valori di uscita specificati nel cluster di inoltro con la parola chiave EXCLUDE vengono trattati come se non fossero esclusivi.

È anche possibile riaccodare un lavoro se il lavoro viene terminato da un segnale.

Se un lavoro viene interrotto da un segnale, il valore di uscita è 128 +valore_segnale. La somma di 128 e il valore del segnale possono essere utilizzati come codice uscita nel parametro REQUEUE_EXIT_VALUES.

Ad esempio, se si desidera che un lavoro venga rieseguito se viene interrotto con un segnale 9 (SIGKILL), il valore di uscita sarà 128 + 9 = 137. È possibile configurare il seguente valore di uscita di riaccodamento per consentire la riaccodamento di un lavoro se è stato interrotto dal segnale 9:

REQUEUE_EXIT_VALUES=137

In Windows, se un lavoro viene interrotto da un segnale, il valore di uscita è signal_value. Il valore del segnale può essere utilizzato come codice di uscita nel parametro REQUEUE_EXIT_VALUES.

Ad esempio, se si desidera rieseguire un lavoro dopo che è stato interrotto con un segnale 7 (SIGKILL), il valore di uscita sarà 7. È possibile configurare il seguente valore di uscita di riaccodamento per consentire a un lavoro di riaccodare dopo che è stato interrotto dal segnale 7:

REQUEUE_EXIT_VALUES=7

È possibile configurare il seguente valore di uscita di riaccodamento per consentire a un lavoro di riaccodare sia per Linux che per Windows dopo che è stato interrotto:

REQUEUE_EXIT_VALUES=137 7

Se mbatchd viene riavviato, non ricorda gli host precedenti da cui il lavoro è stato chiuso con un codice di uscita di riaccodamento esclusivo. In questa situazione, è possibile che un lavoro venga inviato agli host su cui il lavoro è stato precedentemente chiuso con un codice di uscita esclusivo.

Configurare REQUEUE_EXIT_VALUES per le code di riempimento interrompibili (INTERRUPTIBLE_BACKFILL=secondi).

Esempio

REQUEUE_EXIT_VALUES=30 EXCLUDE (20)

significa che i lavori con codice di uscita 30 vengono riaccodati, i lavori con codice di uscita 20 vengono riaccodati esclusivamente e i lavori con qualsiasi altro codice di uscita non vengono riaccodati.

Predefinito

Non definito. I lavori non vengono riaccodati.

Sintassi

RERUNNABLE=yes | no

Descrizione

Se sì, abilita la riesecuzione automatica del lavoro (riavvio) per qualsiasi lavoro associato al profilo dell'applicazione.

La riesecuzione è disabilitata quando RERUNNABLE è impostato su no. Gli argomenti sì e no non sono sensibili al maiuscolo / minuscolo.

È possibile rieseguire i membri di un lavoro di porzioni. Se l'host di esecuzione diventa non disponibile, i membri del lavoro di porzione rieseguibili vengono rimossi dalla porzione del lavoro e inviati a un host di esecuzione differente.

La riesecuzione a livello di lavoro (bsub -r) sovrascrive il valore RERUNNABLE specificato nel profilo applicazione, che sovrascrive la specifica della coda. bmod -rn per rendere i lavori riutilizzabili non riutilizzabili sovrascrive sia il profilo dell'applicazione che la coda.

Predefinito

Non definito.

Sintassi

RES_REQ=req

Descrizione

Le stringhe dei requisiti delle risorse possono essere semplici (si applicano all'intero lavoro), composte (si applicano al numero specificato di slot) o possono contenere risorse alternative (alternative tra 2 o più semplici e / o composti). Quando un requisito di risorsa composta viene impostato a livello di applicazione, verrà ignorato se vengono definiti requisiti di risorsa a livello di lavoro (semplice o composto).

I requisiti di risorsa composti e alternativi seguono la stessa serie di regole per determinare in che modo i requisiti di risorsa verranno uniti tra il lavoro, l'applicazione e il livello di coda. Nel caso in cui non siano impostati requisiti di risorse a livello di lavoro, i requisiti a livello di applicazione composti o alternativi interagiscono con le stringhe di requisiti di risorse a livello di coda nei seguenti modi:

• Quando un requisito di risorsa composta è impostato a livello dell'applicazione, verrà ignorato se sono definiti requisiti di risorsa a livello del lavoro (semplice o composto).
• Se non viene definito alcun requisito di risorsa a livello di coda o viene definito un requisito di risorsa a livello di coda composto o alternativo, viene utilizzato il requisito a livello di applicazione.
• Se è definito un requisito a livello di coda semplice, i requisiti a livello di applicazione e a livello di coda si combinano come segue:

  ---

  sezione	applicazione composta / alternativa e funzionamento della coda semplice
  selezionare	entrambi i livelli soddisfatti; il requisito della coda si applica a tutti i termini
  uguale	livello coda ignorato
  ordine estensione	la sezione a livello dell'applicazione sovrascrive la sezione a livello della coda (se è presente un determinato livello); il requisito della coda (se utilizzato) si applica a tutti i termini
  salsiccia	unione di entrambi i livelli requisito della coda se una risorsa basata sul lavoro viene applicata al primo termine, altrimenti si applica a tutti i termini se si verificano conflitti, la sezione a livello dell'applicazione sovrascrive la sezione a livello della coda. Ad esempio: se il requisito a livello di applicazione ènum1*{rusage[R1]} + num2*{rusage[R2]}e il requisito del livello di coda èrusage[RQ]DoveRQè una risorsa di lavoro, il requisito unito ènum1*{rusage[merge(R1,RQ)]} + num2*{rusage[R2]}

  ---

I requisiti di risorse composte o alternative non supportano la sezione cu o l'operatore | | all'interno della sezione rusage .

Le stringhe di risorse alternative utilizzano l'operatore | | come separatore per ogni risorsa alternativa.

Non è possibile utilizzare più stringhe -R con requisiti di risorse rusage a più fasi.

Per la durata e gli indici di carico interni, i job vengono rifiutati se specificano requisiti di prenotazione delle risorse a livello di lavoro o di applicazione che superano i requisiti specificati nella coda.

Per impostazione predefinita, i limiti di memoria (mem) e di swap (swp) nelle sezioni select [] e rusage [] sono specificati in MB. Utilizzare LSF_UNIT_FOR_LIMITS in lsf.conf per specificare un'unità più grande per questi limiti (GB, TB, PB o EB).

Le stringhe dei requisiti delle risorse nelle sezioni selezionate devono essere conformi ad una sintassi più rigida. La sintassi dei requisiti di risorsa limitata si applica solo alla sezione select . Non si applica alle altre sezioni dei requisiti di risorsa (order, rusage, same, span, cuo affinity). LSF rifiuta le stringhe dei requisiti di risorsa in cui una sezione rusage contiene una risorsa non utilizzabile.

Seleziona sezione

Per i requisiti di risorse semplici,selectla sezione definita a livello di applicazione, coda e lavoro deve essere soddisfatta.

sezione rusage

L'intestazionerusagela sezione può specificare richieste aggiuntive. Per eseguire questa operazione, utilizzare ilOR(||) per separare ulteriorirusage. La sezione di rusage a livello di lavoro ha la precedenza.

sezione ordine

Per i requisiti di risorse semplici,orderla sezione definita a livello di lavoro sovrascrive qualsiasi sezione di ordine a livello di applicazione. Una sezione di ordine a livello di applicazione sovrascrive la specifica a livello di coda. L'intestazioneorderla sezione definita a livello di applicazione viene ignorata se vengono specificati requisiti di risorsa a livello di lavoro. Se nessun requisito di risorsa include unordersezione, l'ordine predefinitor15s:pg.

La sintassi del comando è:

[!][-]resource_name [: [-]resource_name]

Ad esempio:

bsub -R "order[!ncpus:mem]" myjob

"!" funziona solo con le risorse consumabili perché le risorse possono essere specificate nella sezione rusage [] e il loro valore può essere modificato nel ciclo di pianificazione (ad esempio, slot o memoria). Nello scheduler LSF, gli slot RUN, SSUSP, USUP e RSV possono essere liberati in diverse fasi di pianificazione. Pertanto, il valore dello slot può cambiare in diversi cicli di pianificazione.

sezione span

Per i requisiti di risorse semplici,spansezione definita a livello di lavoro sovrascrive una sezione di estensione a livello di applicazione, che sovrascrive una sezione di estensione a livello di coda.

stessa sezione

Per requisiti di risorse semplici, tuttisamele sezioni definite a livello di lavoro, a livello di applicazione e a livello di coda vengono combinate prima della distribuzione del lavoro.

sezione cu

Per i requisiti di risorse semplici, la sezione cu a livello di lavoro sovrascrive il livello di applicazione e la sezione cu a livello di applicazione sovrascrive il livello di coda.

sezione affinità

Per i requisiti di risorse semplici, la sezione affinità a livello di lavoro sovrascrive quella a livello di applicazione e la sezione affinità a livello di applicazione sovrascrive il livello di coda.

Predefinito

select[type==local] order[r15s:pg]

Se questo parametro è definito e viene specificato un modello di host o una risorsa booleana, il tipo predefinito è any.

Descrizione

N|n: la funzione di lavoro ridimensionabile è disabilitata nel profilo dell'applicazione. In questa impostazione, tutti i job collegati a questo profilo dell'applicazione non sono ridimensionabili. Tutti i comandi bresize e bsub -ar verranno rifiutati con un messaggio di errore appropriato.

Y|y: il ridimensionamento è abilitato nel profilo dell'applicazione e tutti i lavori appartenenti all'applicazione sono ridimensionabili per impostazione predefinita. In questa impostazione, gli utenti possono eseguire i comandi bresize per annullare le richieste di assegnazione delle risorse in sospeso per il lavoro o rilasciare le risorse da un'assegnazione lavoro esistente oppure utilizzare bsub per inoltrare un lavoro ridimensionabile.

I lavori ridimensionabili devono essere inoltrati con un profilo applicazione che definisce RESIZABLE_JOBS come auto o Y. Se un'applicazione definisce RESIZABLE_JOBS=auto, ma un amministratore lo modifica in N e riconfigura LSF, i lavori senza l'attributo ridimensionabile automaticamente a livello di lavoro non sono più ridimensionabili automaticamente. Per i lavori in esecuzione che si trovano nella fase di notifica, LSF consente il completamento della notifica corrente e arresta la pianificazione. La modifica della configurazione di RESIZABLE_JOBS non influisce sui lavori con l'attributo autoresizable a livello di lavoro (questo comportamento è lo stesso dei lavori esclusivi, bsub -xe il parametro EXCLUSIVE a livello della coda).

I lavori ridimensionabili possono avere requisiti di risorse alternative e composte. Quando si utilizza bresize release per rilasciare gli slot dai requisiti delle risorse composte, è possibile rilasciare solo gli slot rappresentati dall'ultimo termine del requisito delle risorse composte. Per rilasciare gli slot nei termini precedenti, eseguire ripetutamente bresize release per rilasciare gli slot negli ultimi termini successivi.

Predefinito

Se il parametro non è definito, il valore predefinito è N.

Vedi anche

RESIZABLE_JOBS nell' lsb.params

Descrizione

Definisce un comando eseguibile da richiamare sul primo host di esecuzione di un lavoro quando si verifica un evento di ridimensionamento. La lunghezza massima del comando di notifica è di 4 KB.

Predefinito

Non definito. Non viene richiamato alcun comando di notifica di ridimensionamento.

Sintassi

Descrizione

Il percorso del comando può contenere un massimo di 4094 caratteri per UNIX e Linuxo un massimo di 255 caratteri per Windows, inclusi la directory, il nome file e i valori espansi per %J (ID_lavoro) e %I (ID_indice).

Predefinito

Sintassi

RTASK_GONE_ACTION="[KILLJOB_TASKDONE | KILLJOB_TASKEXIT] [IGNORE_TASKCRASH]"

Descrizione

Definisce le azioni che LSF deve intraprendere se rileva che un'attività remota di un job parallelo o distribuito non è più presente.

Questo parametro si applica solo al framework dell'applicazione distribuita blaunch .

Variabile di ambiente

Quando è definito in un profilo dell'applicazione, la variabile LSB_DJOB_RTASK_GONE_ACTION viene impostata durante l'esecuzione di bsub -app per l'applicazione specificata.

È anche possibile utilizzare la variabile di ambiente LSB_DJOB_RTASK_GONE_ACTION per sovrascrivere il valore impostato nel profilo dell'applicazione.

Esempio

RTASK_GONE_ACTION="IGNORE_TASKCRASH KILLJOB_TASKEXIT"

Predefinito

Non definito. LSF non fa nulla.

Sintassi

RUNLIMIT=[ora:]minuto[/nome_host | /modello_host]

Descrizione

Il limite di esecuzione predefinito. Il nome di un host o di un modello host specifica l'host di normalizzazione di runtime da utilizzare.

Per impostazione predefinita, i lavori che si trovano nello stato RUN per un periodo superiore al limite di esecuzione specificato vengono uccisi da LSF. Facoltativamente, è possibile fornire la propria azione di terminazione del lavoro per sovrascrivere questo valore predefinito.

I lavori inoltrati con un limite di esecuzione a livello di lavoro (bsub -W) inferiore al limite di esecuzione vengono interdati quando viene raggiunto il limite di esecuzione a livello di lavoro. I lavori inoltrati con un limite di esecuzione maggiore del limite massimo di esecuzione vengono rifiutati. I limiti a livello di applicazione sovrascrivono qualsiasi limite predefinito specificato nella coda.

Il limite di esecuzione è nel formato [ora:]minuto. I minuti possono essere specificati come un numero maggiore di 59. Ad esempio, tre ore e mezza possono essere specificate come 3:30 o 210.

Il limite di esecuzione specificato è il runtime normalizzato. Questa operazione viene eseguita in modo che il lavoro faccia approssimativamente la stessa quantità di elaborazione, anche se viene inviato all'host con una CPU più veloce o più lenta. Ogni volta che viene fornito un runtime normalizzato, il tempo effettivo sull'host di esecuzione è il tempo specificato moltiplicato per il fattore CPU dell'host di normalizzazione, quindi diviso per il fattore CPU dell'host di esecuzione.

Se ABS_RUNLIMIT=Y è definito in lsb.params o nel profilo dell'applicazione, il limite di runtime non è normalizzato dal fattore CPU host. Il tempo di esecuzione assoluto del wall - clock viene utilizzato per tutti i lavori inoltrati a un profilo dell'applicazione con un limite di esecuzione configurato.

Facoltativamente, è possibile fornire un nome host o un nome modello host definito in LSF. È necessario inserire '/' tra il limite di esecuzione e il nome host o il nome modello. (Consultare lsinfo(1) per ottenere le informazioni sul modello host.)

Se non viene fornito alcun host o modello host, LSF utilizza l'host di normalizzazione runtime predefinito definito a livello di coda (DEFAULT_HOST_SPEC in lsb.queues) se è stato configurato; altrimenti, LSF utilizza l'host di normalizzazione del tempo CPU predefinito definito a livello di cluster (DEFAULT_HOST_SPEC in lsb.params) se è stato configurato; altrimenti, l'host con il fattore CPU più grande (l'host più veloce nel cluster).

Per i lavori con la funzionalità multicluster LSF, se non è definito alcun altro host di normalizzazione del tempo CPU e le informazioni relative all'host di inoltro non sono disponibili, LSF utilizza l'host con il fattore CPU più grande (l'host più veloce nel cluster).

I lavori inoltrati a una coda lavori di porzioni non vengono sbloccati se RUNLIMIT è maggiore di 30 minuti.

Predefinito

Illimitato

Sintassi

STACKLIMIT=numero intero

Descrizione

Il limite di dimensione del segmento stack per processo (soft) per tutti i processi che appartengono a un lavoro da questa coda (consultare getrlimit(2)). I limiti a livello di applicazione sovrascrivono qualsiasi limite predefinito specificato nella coda, ma devono essere inferiori al limite fisso della coda di inoltro.

Per impostazione predefinita, il limite è specificato in KB. Utilizzare LSF_UNIT_FOR_LIMITS in lsf.conf per specificare un'unità più grande per il limite (MB, GB, TB, PB o EB).

Predefinito

Illimitato

Sintassi

SUCCESS_EXIT_VALUES=[codice_uscita ...]

Descrizione

Specifica i valori di uscita utilizzati da LSF per stabilire se il lavoro è stato eseguito con esito positivo. Utilizzare spazi per separare più codici di uscita. I valori di uscita a livello di lavoro specificati con la variabile di ambiente LSB_SUCCESS_EXIT_VALUES sovrascrivono la configurazione nel profilo dell'applicazione.

Utilizzare SUCCESS_EXIT_VALUES per le applicazioni che escono correttamente con valori diversi da zero, in modo che LSF non interpreti i codici di uscita diversi da zero come errore del lavoro.

exit_code deve essere un valore compreso tra 0 e 255. Utilizzare spazi per separare i valori del codice di uscita.

Se sia SUCCESS_EXIT_VALUES che REQUEUE_EXIT_VALUES sono definiti con lo stesso codice di uscita, REQUEUE_EXIT_VALUES avrà la precedenza e il lavoro verrà impostato sullo stato PEND e riaccodato.

Predefinito

0

Sintassi

Descrizione

Quando il motivo di sospensione SUSP_LOAD_REASON (sospeso dal caricamento) è impostato in LSB_SUSP_REASON, lsb_susp_subreason è impostato su uno dei valori dell'indice di caricamento definiti in lsf.h.

Utilizzare LSB_SUSP_MOTIVI e LSB_SUSP_SUBMOTIVI insieme nel controllo lavoro personalizzato per determinare la soglia di caricamento esatta che ha causato la sospensione di un lavoro.

Il percorso del comando può contenere un massimo di 4094 caratteri per UNIX e Linuxo un massimo di 255 caratteri per Windows, inclusi la directory, il nome file e i valori espansi per %J (ID_lavoro) e %I (ID_indice).

Predefinito

Sintassi

SWAPLIMIT=numero intero

Descrizione

Limita la quantità di limite di memoria virtuale totale per il lavoro.

Questo limite si applica all'intero lavoro, indipendentemente dal numero di processi che il lavoro può contenere. I limiti a livello di applicazione sovrascrivono qualsiasi limite predefinito specificato nella coda.

L'azione intrapresa quando un lavoro supera SWAPLIMIT o PROCESSLIMIT consiste nell'inviare SIGQUIT, SIGINT, SIGTERM e SIGKILL in sequenza. Per CPULIMIT, SIGXCPU viene inviato prima di SIGINT, SIGTERM e SIGKILL.

Per impostazione predefinita, il limite è specificato in KB. Utilizzare LSF_UNIT_FOR_LIMITS in lsf.conf per specificare un'unità più grande per il limite (MB, GB, TB, PB o EB).

Predefinito

Illimitato

Sintassi

TASKLIMIT=[limite_minimo [limite_predefinito]] limite_massimo

Descrizione

Numero massimo di task che possono essere assegnati a un lavoro. Per i job paralleli, il numero massimo di attività che possono essere assegnate al job.

Il livello coda TASKLIMIT ha la priorità più elevata rispetto al livello applicazione TASKLIMIT e al livello lavoro TASKLIMIT. Il livello applicazione TASKLIMIT ha una priorità superiore rispetto al livello lavoro TASKLIMIT. I limiti a livello di lavoro devono rientrare nei limiti massimi e minimi del profilo applicazione e della coda.

Facoltativamente, specifica il numero minimo e predefinito di attività del lavoro. Tutti i limiti devono essere numeri positivi maggiori o uguali a 1 che soddisfano la seguente relazione:

1 < = minimo < = valore predefinito < = massimo

Nel modello di inoltro del lavoro per la funzionalità multicluster LSF, il cluster locale considera la coda di ricezione TASKLIMIT sui cluster remoti prima di inoltrare i lavori. Se la definizione di TASKLIMIT della coda di ricezione nel cluster remoto non può soddisfare i requisiti di attività del lavoro, il lavoro non viene inoltrato a tale coda remota.

Predefinito

Illimitato, il numero predefinito di attività è 1

Sintassi

Descrizione

Il percorso del comando può contenere un massimo di 4094 caratteri per UNIX e Linuxo un massimo di 255 caratteri per Windows, inclusi la directory, il nome file e i valori espansi per %J (ID_lavoro) e %I (ID_indice).

Predefinito

Sintassi

THREADLIMIT=numero intero

Descrizione

Limita il numero di sottoprocessi simultanei che possono far parte di un lavoro. Il superamento del limite causa la chiusura del job. Il sistema invia i seguenti segnali in sequenza a tutti i processi appartenenti al lavoro: SIGINT, SIGTERM e SIGKILL.

Per impostazione predefinita, i lavori inoltrati alla coda senza un limite di sottoprocesso a livello di lavoro vengono terminati quando viene raggiunto il limite di sottoprocesso. I limiti a livello di applicazione sovrascrivono qualsiasi limite predefinito specificato nella coda.

Il limite deve essere un numero intero positivo.

Predefinito

Illimitato

Sintassi

THREADLIMIT=numero_di_thread

Descrizione

Il valore del limite di thread di un lavoro limita il numero di thread contemporanei che possono far parte del lavoro ed è definito nel parametro THREADLIMIT. Il superamento del limite causa la chiusura del job. Il limite deve essere un numero intero positivo.

L'uso del parametro THREADLIMIT_PER_TASK per calcolare il valore del limite di thread di un lavoro consente di utilizzare un limite di thread più raffinato basato sul numero di attività del lavoro. Se specificato, LSF calcola il limite di thread di un lavoro prendendo il valore THREADLIMIT_PER_TASK e moltiplicandolo per il numero di task del lavoro. In questo modo, il limite di thread del lavoro non è un valore fisso per l'intera applicazione.

Il parametro THREADLIMIT_PER_TASK viene utilizzato solo per calcolare il limite di thread del lavoro e non limita il numero di thread per ogni task.

Il parametro THREADLIMIT_PER_TASK non può essere configurato insieme al parametro THREADLIMIT per la stessa coda. Se si specificano entrambi i valori nella stessa applicazione, verrà utilizzato solo il valore THREADLIMIT_PER_TASK e il valore THREADLIMIT verrà ignorato.

Esempio

THREADLIMIT_PER_TASK=10

Predefinito

Non definito

Descrizione

USE_PAM_CREDS è supportata solo su sistemi Linux . Se l'host di esecuzione non dispone di PAM configurato e questo parametro è abilitato, il lavoro non riesce.

Se USE_PAM_CREDS è impostato su y o limits, LSF può applicare i limiti PAM a un'applicazione quando il relativo lavoro viene distribuito a un host Linux utilizzando PAM LSF. Il lavoro LSF non viene eseguito all'interno della sessione PAM.

La parola chiave limits può essere definita insieme alla parola chiave session .

Se i limiti LSF sono più restrittivi dei limiti PAM, vengono utilizzati LSF , altrimenti vengono utilizzati i limiti PAM. I limiti PAM sono limiti per le risorse di sistema definiti nel file limits.conf .

Per i job paralleli, le sessioni PAM vengono avviate solo sul primo host di esecuzione se è definito USE_PAM_CREDS=y o USE_PAM_CREDS=limits . Le sessioni PAM vengono avviate su tutte le attività se è definito USE_PAM_CREDS=session o USE_PAM_CREDS=limits session .

Il daemon sbatchd del lavoro controlla il servizio lsf e il daemon RES del lavoro o dell'attività controlla il servizio lsf-<clustername> .

Sovrascrive MEMLIMIT_TYPE=Process.

Sovrascritto (solo per il limite CPU) da LSB_JOB_CPULIMIT=y.

Sovrascritto (solo per i limiti di memoria) da LSB_JOB_MEMLIMIT=y.

Il valore USE_PAM_CREDS in lsb.applications sovrascrive il valore USE_PAM_CREDS in lsb.queues.

Predefinito

n. USE_PAM_CREDS è disabilitato.

Sintassi

WATCHDOG=script[file/percorso/in/script] init[init_delay] period[start_interval]

Descrizione

Consente a LSF di utilizzare la funzione watchdog per eseguire regolarmente script esterni che controllano i dati dell'applicazione, i log e altre informazioni. LSF può utilizzare questi script per trasmettere informazioni sul lavoro.

Questo parametro utilizza le seguenti parole chiave:

script

Obbligatorio. Questa parola chiave specifica il percorso file dello script watchdog esterno per controllare i dati dell'applicazione e altre informazioni. Questo file deve avere le autorizzazioni appropriate per l'utente di inoltro del lavoro per eseguire lo script.

inizializzare

Facoltativo. Questa parola chiave specifica il ritardo di avvio dello script watchdog dopo l'avvio del lavoro, in secondi. Specificare un numero maggiore di 30 secondi. Il valore predefinito è 60 secondi.

periodo,punto

Facoltativo. Questa parola chiave specifica l'intervallo in cui avviare lo script watchdog dopo l'ora precedente in cui lo script watchdog è stato avviato, in secondi. Specificare un numero maggiore di 30 secondi. Il valore predefinito è 60 secondi.

Tutte le variabili di ambiente del job sono disponibili per gli script watchdog. Inoltre, le seguenti variabili di ambiente di utilizzo delle risorse a livello di lavoro LSF sono disponibili per gli script watchdog:

• LSB_GPU_ALLOC_INFO
• LSB_JOB_AVG_MEM
• LSB_JOB_CPU_TIME
• LSB_JOB_MAX_MEM
• LSB_JOB_MEM
• LSB_JOB_NTHREAD
• LSB_JOB_PGIDS
• LSB_JOB_PIDS
• LSB_JOB_RUN_TIME
• LSB_JOB_SWAP

Predefinito

Non definito.