Uma vez passada essa cota, ainda será possível usar o cluster, mas os seus processos terão uma prioridade cada vez menor em relação a outros usuários que utilizaram menos os recursos. Essa conta leva em consideração uma janela de tempo que é construída considerando uma curva de decaimento exponencial, com tempo de meia vida de 14 dias. Ou seja, a prioridade com que o recursos são disponibilizados para os jobs do usuário vai diminuindo à medida que solicita mais e mais recursos. Porém, a cada 14 dias essa prioridade é reinicializada (retorna ao seu valor máximo para aquele usuário).
Entendendo sobre o FairShare
Vamos supor que que um usuário chamado Spock (cujo login no GridUnesp seja spock) queira avaliar sua cota atual de FairShare. Para isso, ele pode utilizar o comando abaixo.
[spock@access2 ~]$ sshare -a
Hipoteticamente, Spock observa na tela o seguinte:
Account User RawShares NormShares RawUsage EffectvUsage FairShare
------------ --------- ---------- ----------- ----------- ------------- ----------
startrek 10 0.008065 40079089 0.008656
startrek kirk 1 0.333333 1761930 0.043961 0.220126
startrek picard 1 0.333333 38237843 0.954060 0.219227
startrek spock 1 0.333333 79315 0.001979 0.221024
hogwarts 10 0.008065 8028212 0.001734
hogwarts potter 1 0.250000 0 0.000000 0.278527
hogwarts hermione 1 0.250000 8028212 1.000000 0.275831
hogwarts voldemort 1 0.250000 0 0.000000 0.278527
hogwarts malfoy 1 0.250000 0 0.000000 0.278527
starwars 10 0.008065 548 0.000000
starwars yoda 1 0.500000 548 1.000000 0.495058
starwars vader 1 0.500000 0 0.000000 0.495957
Quanto menor o valor na última coluna (FairShare), menor a prioridade. Analiando então o resultado, Spock verifica que quanto mais usuários tem um grupo ao qual o usuário pertença, menor é a prioridade do job dele em obter recursos. Além disso, percebe que quanto mais um usuário usa o cluster, menor é a prioridade dos seus jobs.
Para reduzir a lista considerando apenas os usuários do próprio grupo, Spock poderia usar o comando
[spock@access2 ~]$ sshare -a | grep startrek
E para ver os resultados relacionados apenas da própria conta, Spock poderia usar o comando
[spock@access2 ~]$ sshare -a | grep spock
Para listar os processos em espera em ordem de prioridade, Spock então utiliza o seguinte comando
[spock@access2 ~]$ squeue -o "%.18i %.9Q %.8j %.8u %.10V %.6D %R" --sort=-p,i --states=PD
cujo resultado é
JOBID PRIORITY NAME USER SUBMIT_TIM NODES NODELIST(REASON)
2847404 296816 force1.s yoda 2022-03-31 1 (Priority)
2838783_12 222821 force2.s yoda 2022-03-15 1 (Priority)
2838783_14 222821 dark1.sh vader 2022-03-15 1 (Priority)
2838783_16 222821 dark2.sh vader 2022-03-15 1 (Priority)
2838783_17 222821 dark3.sh vader 2022-03-15 1 (Priority)
2838783_18 222821 dark4.sh vader 2022-03-15 1 (Priority)
2838783_19 222821 dark5.sh vader 2022-03-15 1 (Priority)
2838783_20 222821 dark6.sh vader 2022-03-15 1 (Priority)
2838783_32 222821 dark7.sh vader 2022-03-15 1 (Priority)
2838783_33 222821 dark8.sh vader 2022-03-15 1 (Priority)
2838783_34 222821 dark9.sh vader 2022-03-15 1 (Priority)
2838784 222821 patrono. potter 2022-03-15 1 (Priority)
2844502 185817 crucio1. valdemo+ 2022-03-28 1 (Priority)
2844503 185817 crucio2. valdemo+ 2022-03-28 1 (Priority)
2812260 165420 accio.sh malfoy 2022-01-21 1 (Priority)
2841019 160928 reparo.s hermion+ 2022-03-21 2 (Priority)
2848555 50480 vulcano. spock 2022-04-01 4 (Priority)
2844454 48355 dobra3.s picard 2022-03-28 1 (Priority)
Analiando o resultado, Spock verifica que, dos jobs que estão pendente de recursos, seu job (2848555), está na penúltima posição de prioridade na fila (50480). Então, à medida que os jobs com prioridade maior forem obtendo recursos, o job de Spock irá subindo na fila de prioridades.
Importante
Além da priorização por uso, é sempre válido especificar a menor janela de tempo possível para garantir uma alocação mais rápida dos recursos na fila. Ou seja, o usuário deve buscar otimizar a simulação usando o mínimo de recursos (processos, CPUs, nós) com o mínimo de tempo possível para que seus jobs tenham prioridade maior na fila.
Um exemplo trivial seria a comparação entre jobs que demandam apenas 1 CPU com aqueles que demanda 8, 16, 28, 56, etc. Aqueles (de 1 CPU), em geral, acabam tendo prioridade na fila.
Em resumo, para balancear a disponibilização de recursos, o GridUnesp utiliza a política de FairShare no escalonamento dos jobs. As simulações que requerem pouco tempo de execução e pouco processamento acabam tendo prioridade na fila. Mas não somente isso. O cálculo pelo FairShare é bem mais complexo e leva em consideração outros fatores como a quantidade total de grupos e a quantidade de usuários por grupo, além da quantidade de processos, CPUs e nós solicitados. O FairShare de cada usuário vai reduzindo à medida que ele utiliza o cluster, sendo reinicializado de tempos em tempos (semanas).
Nota
A política de FairShare busca também garantir que não haja recursos idle (ociosos). Destarte, se um job está requisitando a alocação de 56 CPUs em um único nó de processamento, havendo disponível, porém, apenas 20 no total, então um outro job que solicite (na sequência) apenas 16 CPUs com certeza irá obter os recursos demandados. Veja que o segundo job vai usar os recursos ociosos, tendo prioridade em relação àquele primeiro, já que, em tese, aquele demandaria muito mais tempo para obter 56 CPUs em um único worker node.