Existe alguma desvantagem em usar o qsub para executar tarefas o tempo todo?

Question

Quando estou executando uma tarefa em uma rede de computadores? Eu comecei a perceber que, se eu qsub qualquer tarefa, a tarefa não vai monopolizar o meu terminal, e eu posso fazer outras coisas no mesmo terminal (o que é bastante útil mesmo se o tarefa leva apenas um minuto para terminar).

E então eu corro o qstat para ver quais tarefas terminaram e quais não foram concluídas.

link é uma boa explicação do qsub.

    

Answer 1

Nestes casos, prefiro abrir outro terminal. Qual é a razão pela qual você não quer fazer isso?

O lado negativo da execução do qsub é que você precisa escrever um pequeno arquivo de script para uma operação trivial, o que leva algum tempo. Eu não sei quantos outros usuários estão trabalhando na mesma rede, mas o propósito é como um agendador para trabalhos de vários usuários no cluster. Especialmente se não houver núcleos livres disponíveis, seu trabalho simples acabará na fila, levando mais tempo.

Você considerou screen como uma alternativa? Com screen você pode iniciar e pausar uma sessão diferente no mesmo terminal. O fluxo de trabalho seria assim

• trabalhando no terminal
• $ screen
• seus pequenos trabalhos
• Desconecte a tela ( Ctrl - a Ctrl - d )
• trabalhando no terminal
• $ screen -r (para continuar)
• Verifique o status desse pequeno trabalho
• $ exit
• E você está de volta

Answer 2

Não vejo nenhuma vantagem de usar qsub sobre o padrão at . O comando at irá pegar um "script" e executá-lo em uma hora específica (como "agora"), usando seu ambiente atual. Em seguida, você pode verificar o status com atq ou remover o trabalho com atrm .

$ nohup ./myscript myargs & # put script in the background
# almost the same as
$ echo ./myscript myargs | at now # computer runs script independent of terminals

Você precisa ter certeza de que seu myscript não estará procurando informações.

Eu mesmo, eu uso screen em uma única sessão de terminal onde quer que eu vá, como Bernhard sugere. Abra uma nova janela (dentro de screen ), inicie o script, volte para a janela screen original.

    

Answer 3

Não vejo nenhuma desvantagem em usar qsub para trabalhos em segundo plano que normalmente seriam executados de forma interativa dentro da tela. Se você tiver um cluster disponível, essa é a solução ideal.

Apesar de termos um job scheduler disponível, por muito tempo eu usei a tela para executar trabalhos de longa duração ou obter paralelismo sem muita sobrecarga na escrita de scripts do qsub. Eventualmente, as limitações dessa abordagem se tornaram aparentes, e eu escrevi esse wrapper qsub qgo para permitir que eu substituísse & e screen por qsub :

#!/bin/bash

mkdir -p qsubscripts

qsub -w $(pwd)/qsubscripts -d $(pwd) -M [email protected] $@ -S /bin/zsh -

Note que estou usando meu shell preferido (zsh), mas é claro que você pode remover esse argumento ou adicionar outros. O uso de $@ permite a inclusão de especificações de recursos como -l ncpus=4 , conforme necessário. Veja como você usaria o script:

echo 'command -a 23 -b zz' | qgo | tee jobids

Os arquivos STDERR.* e STDOUT.* serão gravados em qsubscripts no diretório de trabalho atual. Os IDs do trabalho também são fornecidos no The working directory for the job is set as the cwd ', o que facilita a gravação desses scripts curtos.