Cadeia de pedidos

A sequência de pedidos permite que os hosts selecionados sejam classificados de acordo com os valores de recursos. Os valores de r15s, r1m, e r15m usados para classificação são os índices de carga normalizados que são retornados por lsload -N.

A sequência de pedidos é usada para triagem e seleção de hospededoras. A ordenação começa com o índice direitomais na sequência de pedidos e procede da direita para a esquerda. Os hosts são classificados em ordem com base em cada índice de carga, e se mais hosts estão disponíveis do que foram solicitados, o LIM elimona os hosts menos desejáveis de acordo com esse índice. Os demais hospedeiros são então classificados pelo próximo índice.

Depois que os hosts são classificados pelo índice mais à esquerda na sequência de pedidos, a fase final de classificação ordena os hosts de acordo com seu status, com hosts que atualmente não estão disponíveis para compartilhamento de carga (ou seja, não no estado ok ) listado no final.

Como os hosts são classificados novamente para cada índice de carregamento, apenas o status do host e o índice de esquerda na string de ordem realmente afetam a ordem em que os hosts são listados. Os demais índices são usados apenas para eliminar hosts indesejáveis da lista.

Quando a classificação é feita em cada índice, a direção na qual os hosts são classificados (aumentando versus valores decrescentes) é determinado pela ordem padrão devolvida por lsinfo para esse índice. Esta direção é escolhida de tal forma que após a classificação, por padrão, os hosts são ordenados de melhor para pior sobre esse índice.

Quando usado com uma string cu , a ordem de unidade de cálculo preferida tem precedência. Dentro de cada unidade de cálculo os hosts são ordenados de acordo com os requisitos de string order .

Sintaxe

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

Você pode especificar qualquer índice de carregamento ou recurso estático embutido ou externo.

A sintaxe ! classificam os hosts candidatos. Ele se aplica a toda a seção order [] . Depois que os hosts candidatos são selecionados e classificados inicialmente, eles são classificados novamente antes de uma tarefa ser agendada por todos os plug-ins. ! é o primeiro caractere na sequência de order [] mesclado se você especificar.

! só funciona com recursos consumíveis porque os recursos podem ser especificados na seção order [] e o seu valor pode ser alterado em ciclo de planejamento (por exemplo, slot ou memória). Para o planejador, slots em RUN, SSUSP, USUP e RSV podem se tornar livres em diferentes fases de planejamento. Portanto, o valor do slot pode mudar em diferentes ciclos de agendamento.

Usar slots para ordenar hospedeiros de candidatos pode nem sempre melhorar a utilização de cluster inteiro. A utilização do cluster depende de muitos fatores.

Quando um nome de índice é precedido por um sinal de menos '-', a ordem de classificação é revertida para que os hosts sejam ordenados de pior a melhor sobre esse índice.

No exemplo a seguir, a LSF primeiro tenta fazer as malas de trabalho em hosts com os menos slots. São apresentados três trabalhos em série e um trabalho paralelo.

HOST_NAME STATUS JL/U MAX NJOBS RUN SSUSP USUSP RSV

hostA ok - 4 0 0 0 0 0

hostB ok - 4 0 0 0 0 0

Os três trabalhos em série são submetidos:

bsub -R "order[-slots]" job1
bsub -R "order[-slots]" job2
bsub -R "order[-slots]" job3

O trabalho paralelo é enviado:

bsub -n 4 -R "order[-slots] span[hosts=1]" sleep 1000

Os jobs de série são despachados para um host (hostA). O trabalho paralelo é despachado para outro hospedeiro.

Alterar a ordem de classificação padrão do LSF

Você pode alterar a ordem de classificação padrão do sistema LSF global de requisitos de recursos para que o planejador possa encontrar o host de candidato certo. Isso torna mais fácil a manutenção de uma única ordem padrão global em vez de ter que configurar uma ordem padrão no arquivo lsb.queues para cada fila definida no sistema. Você também pode especificar uma ordem padrão para substituir o valor de sorteio padrão der15s:pg, o que poderia impactar o desempenho em clusters de grande escala.

Para configurar a ordem padrão, é possível utilizar o parâmetro DEFAULT_RESREQ_ORDER em lsb.params. Por exemplo, você pode empacotar trabalhos em hosts com os slots livres do fewest configurando DEFAULT_RESREQ_ORDER=-slots:-maxslots. Isso irá despachar empregos para o host com os slots livres do feoeste e em segundo lugar para os hosts com o menor número de vagas de vagas definidas (MXJ). Isso deixará blocos maiores de slots livres nos hosts com MXJ maior (se a utilização do slot no cluster não for muito alta).

Comandos com o parâmetro -R (como bhosts, bmod e bsub) utilizarão a ordem padrão definida em DEFAULT_RESREQ_ORDER para agendamento se nenhum pedido for especificado no comando.

Para alterar a ordem de classificação padrão do sistema:

Configure o DEFAULT_RESREQ_ORDER em lsb.params.
Execute badmin reconfig para que as alterações sejam efetivadas.
Opcional: Executar bparams -a | grep ORDER para verificar se o parâmetro foi configurado. Saída similar à mostrada no exemplo a seguir aparece:

DEFAULT_RESREQ_ORDER = r15m:it
Envie seu trabalho.

Ao verificar a saída, é possível ver a ordem de classificação para os requisitos de recursos na seção RESOURCE REQUIREMENT DETAILS :

bjobs -l 422
Job <422>, User <lsfadmin>, Project <default>
Status <DONE>, Queue <normal>, Command <sleep1>
Fri Jan 18 13:29:35: Submitted from hostA, CWD
                     <home/admin/lsf/conf/lsbatch/LSF/configdir>;
Fri Jan 18 13:29:37: Started on <hostA>, Execution Home </home/lsfadmin>,
Execution CWD </home/admin/lsf/conf/lsbatch/LSF/configdir>;
Fri Jan 18 13:29:44: Done successfully. The CPU time used is 0.0 seconds.
 
  MEMORY USAGE:
  MAX MEM: 3 Mbytes;  AVG MEM: 3 Mbytes
 
  SCHEDULING PARAMETERS:
          r15s   r1m  r15m   ut      pg    io   ls    it    tmp    swp   mem
loadSched   -     -     -     -       -     -    -     -     -      -      -
loadStop    -     -     -     -       -     -    -     -     -      -      -
 
RESOURCE REQUIREMENT DETAILS:
Combined: select[type == local] order[r15m:it]
Effective: select[type == local] order[r15m:it]

Ao alterar o valor para DEFAULT_RESREQ_ORDER, observe o seguinte:

Para o agendamento de tarefas, há três níveis nos quais você pode classificar recursos da seção de pedidos: nível de emprego, nível de aplicação e nível de fila. A ordem de classificação para os requisitos de recursos definidos no nível de emprego sobrescreve aqueles definidos no nível de aplicação ou no nível de fila. A ordem de classificação para os requisitos de recursos definidos no nível do aplicativo sobrescreve aqueles definidos no nível da fila. Se nenhuma ordem de classificação for definida em qualquer nível, mbschd usa o valor de DEFAULT_RESREQ_ORDER ao programar o job.
Você só deve classificar por um ou dois recursos já que pode demorar mais para classificar com mais.
Uma vez que a tarefa esteja em execução, não é possível redefinir a ordem de classificação. No entanto, você ainda pode alterá-lo enquanto o trabalho estiver no estado PEND.
Para os modos de locação MultiCluster forward e MultiCluster , o valor DEFAULT_RESREQ_ORDER para cada cluster local é usado.
Se você alterar DEFAULT_RESREQ_ORDER então refila um job em execução, o job utilizará o novo valor DEFAULT_RESREQ_ORDER para agendamento.

Especifique vários -R opções

bsub aceita várias opções -R para a seção de pedidos.

Restrição:

Os requisitos de recursos compostos não suportam várias opções -R .

Você pode especificar várias strings de exigência de recursos em vez de usar o & & operador. Por exemplo:

bsub -R "order[r15m]" -R "order[ut]"

LSF mescla as múltiplas opções -R em uma string e despacha o job se todos os requisitos de recursos puderem ser atendidos. Ao permitir várias strings de exigência de recursos e automaticamente mesclando-as em uma string, LSF simplifica o uso de várias camadas de scripts wrapper. O número de seções de opção -R é ilimitado.

Padrão

A ordem de classificação padrão é r15s:pg: ls:r1m).

swp:r1m:tmp:r15s

Empregos redimentáveis

A ordem em que os hosts são considerados para redimensionar solicitações de alocação é determinada pela expressão order da tarefa. Por exemplo, para executar um trabalho autoresizável em 1-100 slots, preferindo hosts com memória maior, a submissão de tarefas a seguir especifica esta solicitação de recurso:

bsub -ar -app <appplicaion_file> -n "1,100" -R "rusage[swp=100,license=1]" myjob

Quando os slots em vários hosts se tornam disponíveis simultaneamente, os hosts com memória maior disponível obtêm preferência quando o job adicionar slots.

Nota:

Os empregos redimentados não podem ter requisitos de recursos compostos ou alternativos.

Reordenar hosts

Você pode reordenar hosts usando a sintaxe order[! ] .

Suponha que o host h1 exista em um cluster e tenha 110 unidades de um recurso consumível 'res' enquanto o host h2 tem 20 deste recurso ('res' pode ser o novo recurso integrado de lote slots, por exemplo). Suponha que esses dois trabalhos estejam pendentes e sendo considerados por planejador em um mesmo ciclo de planejamento, e o job1 será agendado primeiro:

Job1: bsub -R “maxmem>1000” -R “order[res] rusage[res=100]” -q q1 sleep 10000

Job2: bsub -R “mem<1000” -R “order[res] rusage[res=10]” -q q2 sleep 10000

No início do ciclo de agendamento, uma lista de hosts candidatos é construída considerando todos os hosts do cluster ou os hosts listados em qualquer lista de hosts solicitada. (-m) e ordená-los pela seção de pedido da sequência de requisitos de recursos. Suponha que as listas de acolhimento de candidatos ordenados para os empregos se partem assim após a ordenação:

Job1:{h1, h7, h4, h10}

Job2:{h1, h2}

Isso significa que h1 acaba sendo o mais alto 'res' host as listas de host de ambos os empregos. Em agendamento posterior apenas, um por um cada job será alocado hosts para execução em e recursos desses hosts.

Suponha que o Job1 esteja programado para pousar no host h1, e assim será alocado 100 'res'. Em seguida, quando Job2 é considerado, ele também pode estar programado para pousar no host h1 porque sua lista de host candidato ainda parece a mesma. Ou seja, ele não leva em conta os 100 'res' alocados para Job1 dentro deste mesmo ciclo de planejamento. Para resolver esse problema, use ! no início da seção de pedidos para forçar o planejador a reordenar listas de host candidatas para trabalhos na fase de agendamento posterior:

Job1: bsub -R “maxmem>1000” -R “order[!res] rusage[res=100]” -q q1 sleep 10000

Job2: bsub -R “mem <1000” -R “order[!res] rusage[res=10]” -q q2 sleep 10000

O ! força uma reordenação da lista de host do candidato do Job2para Job2: {h2, h1} desde que o Job1 é alocado 100 'res' em h1, h1 terá 10 'res' (110-100) enquanto que o h2 terá 20.

Você pode combinar novos recursos integrados de lote slots / maxslots com a ordenação reversa e a reordenação para melhor garantir que grandes empregos paralelos terão a chance de correr mais tarde (embalagem melhorada). Por exemplo:

bsub -n 2 -R “order[!-slots:maxslots]” ...

bsub -n 1 -R “order[!-slots:maxslots]” ...