Qsub Submit Binário Opções

O envio de binários no Grid Engine 6.x Grid Engine 6 suporta a submissão direta de binários via qsub e qrsh através do novo argumento - b yn. O comportamento padrão assume - b n. Use - b para invocar diretamente um executável binário. Workgroupcluster: www qrsh - b y usrbinuptime 7:49 up 107 dias, 35 mins, 0 usuários, médias de carga: 0.12 0.03 0.01 workgroupcluster: O comando qsub (1) não pode ser usado para enviar diretamente arquivos binários como trabalhos. Embora seja possível escrever um pequeno script de wrapper em torno de binários para enviá-los, existem duas técnicas convenientes para enviar binários como trabalhos muito simplesmente, sem envolver um script separado. Digite o comando qsub, juntamente com todos os sinalizadores e opções desejados, depois pressione retornar sem especificar um script de trabalho. Você verá um prompt de shell secundário. Com este prompt, você pode digitar o nome do binário. Você pode então pressionar retornar e continuar a inserir mais comandos binários ou shell. Quando terminar de especificar seu trabalho, pressione Control-D. Qsub - l archsolaris64 sleep 60 ltctrl-Dgt seu trabalho 47427 (quotSTDINquot) foi enviado Digite o comando qsub, juntamente com os sinalizadores e opções desejados, use a construção de redirecionamento STDIN ltlARERER. Digite uma ou mais linhas contendo qualquer combinação de binários e comandos de shell no prompt secundário como acima. Então, em uma linha por si só, digite o ltMARKERgt e pressione retornar. Qsub - N teste ltlt EOF sleep 60 EOF seu trabalho 47428 (quottestquot) foi submetido Ambas as técnicas acima aproveitam o fato de que qsub usa o fluxo STDIN como um script de trabalho se você não especificar um arquivo de script como um argumento. Para integrar de forma transparente certas aplicações em seu ambiente com um cluster do Grid Engine, talvez seja necessário escrever um script wrapper personalizado que faça algum trabalho de configuração antes de executar um trabalho. A segunda técnica de cima pode ser incorporada em tais scripts de wrapper. Exemplo: crie o wrapper para enviar um trabalho em lote binário de um SunRay para um farm back-end. Para fazer isso, é necessário modificar a variável LDPRELOAD para remover a entrada específica do SunRay. Um link genérico de envoltório binário do quotqbsubquot pode ser encontrado neste link. Ele pode ser usado como uma versão quotbinary de qsub. O script do wrapper permite que o remetente use os sinalizadores de submissão padrão e também representa os sinalizadores especificados no arquivo qtask (que é usado pelo qtcsh ao enviar de forma transparente binários ao sistema). Um exemplo de uso deste script é: Isso executa o binário netscape enquanto mantém explicitamente a variável de ambiente DISPLAY. NOTA: você, claro, precisa garantir que o binário corresponda à arquitetura em que ele eventualmente será executado. Você pode especificar isso, por exemplo, ao fazer: Sun Grid Engine (SGE) QuickStart O sistema de enfileiramento do Sun Grid Engine é útil quando você tem muitas tarefas para executar e deseja distribuir as tarefas em um conjunto de máquinas. Por exemplo, talvez seja necessário executar centenas de simulações com diferentes parâmetros ou precisar converter 300 vídeos de um formato para outro. O uso de um sistema de enfileiramento nestas situações tem as seguintes vantagens: Agendamento - permite agendar uma quantidade praticamente ilimitada de trabalho a ser executada quando os recursos estiverem disponíveis. Isso significa que você pode simplesmente enviar tantas tarefas (ou tarefas) como quiser e deixar que o sistema de enfileiramento lide executá-las todas. Balanceamento de carga - distribui automaticamente tarefas em todo o cluster, de modo que qualquer nó ndd8217t seja sobrecarregado em comparação com o resto. MonitoringAccounting - capacidade de monitorar todos os trabalhos enviados e consultar quais os nodos de cluster they8217re em execução, se eles foram concluídos, encontrado um erro, etc. Também permite consultar histórico de tarefas para ver quais tarefas foram executadas em uma determinada data, por um determinado usuário, etc. Claro, só porque um sistema de filas está instalado não significa que você precisa usá-lo. Você pode executar suas tarefas em todo o cluster da maneira que você entender e o sistema de filas não deve interferir. No entanto, você provavelmente irá acabar precisando implementar os recursos acima de alguma forma, a fim de utilizar de maneira otimizada o cluster. Envio de trabalhos Um trabalho no SGE representa uma tarefa a ser executada em um nó no cluster e contém a linha de comando usada para iniciar a tarefa. Um trabalho pode ter requisitos específicos de recursos, mas, em geral, deve ser agnóstico em relação ao nó no cluster em que ele é executado enquanto seus requisitos de recursos forem atendidos. Todos os trabalhos exigem pelo menos um slot disponível em um nó no cluster para executar. Enviar tarefas é feito usando o comando qsub. Let8217s tentam enviar um trabalho simples que executa o comando hostname em um determinado nó de cluster: A opção - V para qsub indica que o trabalho deve ter as mesmas variáveis ​​de ambiente que o shell qsub (recomendado). A opção - b para qsub afirma que o O comando que está sendo executado pode ser um único executável binário ou um script bash. Nesse caso, o comando hostname é um único binário. Esta opção leva um argumento y ou n, indicando sim sim o comando é um binário ou não, não é um binário. A opção - cwd para qsub diz ao Sun Grid Engine que o trabalho deve ser executado no mesmo diretório que o qsub foi chamado. O último argumento para qsub é o comando a ser executado (nome do host neste caso) Observe que o comando qsub, quando for bem-sucedido, imprimirá o número do trabalho para stdout. Você pode usar o número do trabalho para monitorar o status do job8217s e avançar dentro da fila como we8217ll ver na próxima seção. Monitorando Jobs na fila Agora que nosso trabalho foi enviado, let8217s veja o status do job8217s na fila usando o comando qstat: A partir desta saída, podemos ver que o trabalho está no estado qw que está em fila e esperando . Após alguns segundos, o trabalho passará para um r. Ou correndo. Indique em qual ponto o trabalho começará a ser executado: uma vez que o trabalho tenha terminado, o trabalho será removido da fila e não aparecerá na saída de qstat: agora que o trabalho terminou let8217s vá para a próxima seção para ver Como vemos um resultado do job8217s. Visualizando um Job8217s Output Sun Grid Engine cria arquivos stdout e stderr no diretório de trabalho job8217s para cada trabalho executado. Se quaisquer arquivos adicionais forem criados durante a execução do job8217s, eles também estarão localizados no diretório de trabalho do job8217s, a menos que seja explicitamente salvo em outro lugar. Os arquivos stdout e stderr do job8217s são nomeados após o trabalho, com a extensão terminada no número do job8217s. Para o trabalho simples enviado acima, temos: Observe que o Sun Grid Engine nomeou automaticamente o nome do host do trabalho e criou dois arquivos de saída: hostname. e1 e hostname1. O e significa stderr e o o para stdout. O 1 no final da extensão files8217 é o número do trabalho. Então, se o trabalho tivesse sido nomeado mynewjob e fosse o trabalho 23 enviado, os arquivos de saída se veriam como: Monitorando o Uso do Cluster Depois de um tempo você pode estar curioso para ver a carga no Sun Grid Engine. Para fazer isso, usamos o comando qhost: A saída mostra a arquitetura (ARCH), o número de cpus (NCPU), a carga atual (LOAD), a memória total (MEMTOT) e a memória usada atualmente (MEMUSE) e o espaço de troca ( SWAPTO) para cada nó. Você também pode ver a carga média (loadavg) por nó usando a opção 8216-f8217 para qstat: Criando um script de trabalho Na seção 8216Submiting Job8217, enviamos um nome de host de comando único. Isso é útil para trabalhos simples, mas para trabalhos mais complexos, onde precisamos incorporar alguma lógica, podemos usar um chamado script de trabalho. Um script de trabalho é essencialmente um script bash que contém alguma lógica e executa qualquer número de scripts de programas externos: como você pode ver, este script executa apenas alguns comandos (como eco, data, gato, etc.) e saídas. Qualquer coisa impressa na tela será colocada no arquivo stdout do job8217s pelo Sun Grid Engine. Uma vez que este é apenas um script bash, você pode colocar qualquer forma de lógica necessária no script do trabalho (ou seja, instruções if, while loops, para loops, etc.) e você pode ligar para qualquer número de programas externos necessários para concluir o trabalho. Let8217s vêem como você executa esse novo script de trabalho. Salve o script acima para homesgeadminjobscript. sh no seu StarCluster e execute o seguinte como o usuário do sgeadmin: Agora que o trabalho foi enviado, let8217s chamam qstat periodicamente até o trabalho ter terminado, já que este trabalho deve demorar um segundo a ser executado uma vez executado : Agora que o trabalho está terminado, let8217s dê uma olhada nos arquivos de saída: vemos de ver a saída que o arquivo stdout contém a saída das instruções eco, data e gato no script do trabalho e que o arquivo stderr é Significado em branco, não houve erros durante a execução do trabalho8217s. Caso alguma falha, como um erro de comando não encontrado, por exemplo, esses erros apareceriam no arquivo stderr. Excluindo um trabalho da fila E se um trabalho estiver preso na fila, está demorando demais para ser executado ou simplesmente começou com parâmetros incorretos Você pode excluir um trabalho da fila usando o comando qdel no Sun Grid Engine. Abaixo, lançamos um trabalho simples de 8216sleep8217 que dorme por 10 segundos para que possamos matá-lo usando qdel: depois de executar o qdel you8217ll aviso, o trabalho desapareceu da fila: OpenMPI e Sun Grid Engine OpenMPI devem ser compilados com suporte SGE (8211with-sge ) Para fazer uso da integração apertada entre OpenMPI e SGE conforme documentado nesta seção. Este é o caso de todos os AMIs públicos do StarCluster8217s. O OpenMPI suporta integração apertada com o Sun Grid Engine. Essa integração permite que o Sun Grid Engine lide com a atribuição de hosts a trabalhos paralelos e para contabilizar adequadamente trabalhos paralelos. OpenMPI Parallel Environment O StarCluster, por padrão, configura um ambiente paralelo, chamado 8220orte8221, que foi configurado para integração OpenMPI dentro do SGE e possui uma série de slots iguais ao número total de processadores no cluster. Você pode inspecionar o ambiente paralelo SGE executando: Esta é a configuração padrão para um cluster de dois nós, c1.xlarge (16 núcleos virtuais). Round Robin vs Fill Up Modes Observe a configuração allocationrule na saída do comando qconf na seção anterior. Isso define como atribuir slots a um trabalho. Por padrão, o StarCluster configura a alocação roundrobin. Isso significa que, se um trabalho solicitar 8 slots, por exemplo, ele irá para a primeira máquina, pegue um único slot, se disponível, mude para a próxima máquina e pegue um único slot, se disponível, e assim enrolando o cluster novamente, se necessário Para alocar 8 slots para o trabalho. Você também pode configurar o ambiente paralelo para tentar localizar os slots o máximo possível usando a regra de alocação de preenchimento. Com esta regra, se um usuário solicitar 8 slots e uma única máquina possui 8 slots disponíveis, esse trabalho será executado inteiramente em uma máquina. Se 5 slots estiverem disponíveis em um host e 3 em outro, serão necessários todos os 5 nesse host, e todos os 3 no outro host. Em outras palavras, esta regra ganhará todos os slots em um determinado nó até que o requisito do slot para o trabalho seja cumprido. Você pode alternar entre roundrobin e modos de preenchimento usando o seguinte comando: Isso abrirá vi (ou qualquer editor definido na variável ED EDITOR) e permitirá que você edite as configurações de ambiente paralelo. Para mudar de roundrobin para preencher o exemplo acima, altere a linha allocationrule de: Enviando Trabalhos OpenMPI usando um Ambiente Paralelo O fluxo de trabalho geral para executar o código MPI é: Compile o código usando mpicc, mpicxx, mpif77, mpif90, etc. Copie o resultado Executável no mesmo caminho em todos os nós ou em um local compartilhado NFS no nó mestre. É importante que o caminho para o executável seja idêntico em todos os nós para que o mpirun lance corretamente seu código paralelo. A abordagem mais fácil é copiar o executável em algum lugar em casa no nó mestre, uma vez que a casa é compartilhada por NFS em todos os nós no cluster. Execute o código no número X de máquinas usando: onde o arquivo host se parece com algo: No entanto, ao usar um ambiente paralelo SGE com o OpenMPI, você não precisa mais especificar as opções - np, - hostfile, - host, etc. para mpirun. Isso ocorre porque o SGE atribuirá automaticamente hosts e processadores para serem usados ​​pelo OpenMPI para o seu trabalho. Você também não precisa passar as opções 8211byslot e 8211bynode para mpirun, dado que esses mecanismos são agora manipulados pelos modos fillup e roundrobin especificados no ambiente paralelo SGE. Em vez de usar a formulação acima, crie um script de trabalho simples que contenha uma chamada mpirun muito simplificada: Em seguida, envie o trabalho usando o comando qsub e o ambiente paralelo orte configurado automaticamente para você pelo StarCluster: as espécies de opção - pe que envolvem o ambiente paralelo e Quantos slots solicitar. O exemplo acima solicita 24 slots (ou processadores) usando o ambiente paralelo orte. O ambiente paralelo cuida automaticamente de distribuir o trabalho MPI entre os nós SGE usando a regra de alocação definida nas configurações do ambiente8217s. Você também pode fazer isso sem um script de trabalho, assim: qsub (1) - Página do manual do Linux Esta página do manual faz parte do POSIX Programmers Manual. A implementação do Linux desta interface pode ser diferente (consulte a página de manual do Linux correspondente para obter detalhes sobre o comportamento do Linux), ou a interface pode não ser implementada no Linux. Qsub - enviar um script Descrição Para enviar um script é criar um trabalho em lote que executa o script. Um script é enviado por um pedido para um servidor em lote. O utilitário qsub é um cliente de lote acessível ao usuário que envia um script. Após a conclusão bem sucedida, o utilitário qsub deve ter criado um trabalho em lote que executará o script enviado. O utilitário qsub deve enviar um script enviando um pedido de tarefa de fila para um servidor em lote. O utilitário qsub deve colocar o valor das seguintes variáveis ​​de ambiente no atributo VaribleList do trabalho em lote: HOME. LANG. LOGNAME. CAMINHO. CORREIO. CONCHA . E TZ. O nome da variável de ambiente deve ser o nome atual com o prefixo PBSO. Nota: Se o valor atual da variável HOME no espaço do ambiente do utilitário qsub for aabbcc. Então qsub deve colocar PBSOHOME aabbcc no atributo VariableList do trabalho em lote. Além das variáveis ​​descritas acima, o utilitário qsub deve adicionar as seguintes variáveis ​​com os valores indicados à lista de variáveis: PBSOWORKDIR O caminho absoluto do diretório de trabalho atual do processo do utilitário qsub. PBSOHOST O nome do host no qual o utilitário qsub está sendo executado. O utilitário qsub deve estar em conformidade com o volume Definições básicas do IEEE Std 1003.1-2001, Seção 12.2, Diretrizes de sintaxe de utilidade. As seguintes opções devem ser suportadas pela implementação: - a datetime Defina o tempo em que um trabalho em lote torna-se elegível para execução. O utilitário qsub deve aceitar um argumento de opção que esteja em conformidade com a sintaxe do operando de tempo do utilitário de toque. Tabela: Valores da variável de ambiente (Utilitários) Nota: O servidor que inicia a execução do trabalho em lote adicionará othervariables ao ambiente de tarefas em lote, veja Execução do trabalho em lote. O utilitário qsub deve configurar o atributo ExecutionTime do trabalho em lote no número de segundos desde que o Epoch é equivalente ao tempo local expresso pelo valor do período de opção de data e hora. A Epoch é definida no volume Definições de Banco de IEEE Std 1003.1-2001, Seção 3.149, Epoch. Operands Arquivos de Entrada Variáveis ​​de Ambiente Eventos AssíncronosSubmitando seu Trabalho em Lote Como Enviar um Trabalho em Lote Os trabalhos de lote não interativos são enviados com o comando qsub. A forma geral do comando é: Por exemplo, para enviar o comando printenv para o sistema de lote, execute: A opção - b y informa ao sistema de lote que o seguinte comando é um executável binário. A mensagem de saída do comando qsub imprimirá o ID do trabalho, que você pode usar para monitorar o status do job8217s dentro da fila. Enquanto o trabalho está sendo executado, o sistema de lote cria arquivos stdout e stderr no diretório de trabalho do job8217s, que são nomeados após o trabalho, com a extensão final no número do job8217s, para o exemplo acima printenv. o jobID e printenv. e jobID. O primeiro conterá a saída do comando eo segundo terá a lista de erros, se houver, que ocorreram enquanto o trabalho estava em execução. Ao executar um programa que requer argumentos e passa opções adicionais para o sistema em lote, ele se torna rapidamente útil para salvá-los em um arquivo de script e enviar esse script como um argumento para o comando qsub. Por exemplo, o script script. sh a seguir executará um trabalho MATLAB simples: Nota: Para ser processado corretamente, o script deve conter uma linha em branco no final do arquivo. Para enviar este arquivo script. sh para o sistema de lote, execute: Para procedimentos de lote MATLAB adicionais, consulte Correndo MATLAB Batch no SCC. Diretrizes gerais de submissão de trabalho Existem várias diretivas (opções) que o usuário pode passar para o sistema de lote. Essas diretivas podem ser fornecidas como argumentos para o comando qsub ou incorporadas no script do trabalho. Em um arquivo de script, as linhas que contêm essas diretivas começam com os símbolos 8211 aqui é um exemplo: Abaixo está a lista das diretivas mais comumente usadas: