Qsub submit binary options

Submeter binários no Grid Engine 6.x O Grid Engine 6 suporta a submissão direta de binários via qsub e qrsh via o novo argumento - b yn. O comportamento padrão assume - b n. Use - b y para invocar diretamente um executável binário. Workgroupcluster: www qrsh - b y / usr / bin / uptime 7:49 até 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 jobs. Embora se possa escrever um pequeno script wrapper em torno de binários para enviá-los, existem duas técnicas convenientes para enviar binários como trabalhos de forma muito simples, sem envolver um script separado. Digite o comando qsub, junto com quaisquer opções e sinalizadores desejados e, em seguida, pressione return sem especificar um script de job. Você verá um prompt do shell secundário. Neste prompt, você pode digitar o nome do binário. Você pode então pressionar retornar e continuar a digitar mais comandos binários ou shell. Quando terminar de especificar seu trabalho, pressione Control-D. Qsub - l archsolaris64 sleep 60 ltctrl-Dgt o seu trabalho 47427 (quotSTDINquot) foi enviado Digite o comando qsub, juntamente com quaisquer sinalizadores e opções desejados, em seguida, use a construção de redirecionamento STDIN ltlt ltMARKERgt. Digite uma ou mais linhas contendo qualquer combinação de binários e comandos shell no prompt secundário como acima. Em seguida, em uma linha por si só, digite o ltMARKERgt e pressione retornar. Qsub - N teste ltlt EOF sono 60 EOF seu trabalho 47428 (quottestquot) foi submetido Ambas as técnicas acima aproveitar o fato de qsub usa o fluxo STDIN como um script de trabalho, se você não especificar um arquivo de script como um argumento. Para integrar perfeitamente determinados aplicativos em seu ambiente com um cluster do Grid Engine, talvez seja necessário gravar um script de 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 um wrapper para enviar um trabalho batch 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 binário genérico submit wrapper script quotqbsubquot pode ser encontrado neste link. Ele pode ser usado como uma versão quotbinary de qsub. O script wrapper permite que o remetente use os sinalizadores de envio padrão e também contabiliza 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 do netscape enquanto mantém explicitamente a variável de ambiente DISPLAY. NOTA: é claro que você precisa garantir que o binário corresponda à arquitetura na qual ele será executado. Você pode especificar isso, por exemplo: Sun Grid Engine (SGE) QuickStart O sistema de enfileiramento do Sun Grid Engine é útil quando você tem um monte de tarefas a serem executadas e deseja distribuir as tarefas em um cluster de máquinas. Por exemplo, talvez seja necessário executar centenas de simulações / experimentos com parâmetros variáveis ​​ou precisar converter 300 vídeos de um formato para outro. Usar um sistema de enfileiramento nessas situações tem as seguintes vantagens: Agendamento - permite que você agende uma quantidade praticamente ilimitada de trabalho a ser executado quando os recursos estiverem disponíveis. Isso significa que você pode simplesmente enviar quantas tarefas (ou tarefas) quiser e deixar que o sistema de filas manipule a execução de todas elas. Balanceamento de carga - distribui automaticamente tarefas em todo o cluster, de modo que qualquer nó não se sobrecarregue em comparação com o resto. Monitoramento / Contabilidade - capacidade de monitorar todos os trabalhos enviados e consultar quais nós de cluster estão sendo executados, se eles terminaram, encontraram um erro, etc. Também permite consultar o histórico de tarefas para ver quais tarefas foram executadas em uma determinada data, por um determinado usuário, Etc Naturalmente, apenas porque um sistema de filas está instalado doesn8217t significa que você tem que usá-lo em tudo. Você pode executar suas tarefas em todo o cluster de qualquer maneira que você entenda e o sistema de filas não deve interferir. No entanto, você provavelmente vai acabar precisando implementar os recursos acima de alguma forma, a fim de utilizar otimamente o cluster. Enviando trabalhos Um trabalho em 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 de recursos específicos, mas em geral deve ser agnóstico para o nó no cluster em que ele é executado, desde que seus requisitos de recursos sejam atendidos. Todos os trabalhos exigem pelo menos um slot disponível em um nó no cluster para ser executado. A submissão de trabalhos é feita usando o comando qsub. Let8217s tentar submeter um trabalho simples que executa o comando hostname em um determinado nó de cluster: A opção - V para qsub afirma que o job deve ter as mesmas variáveis ​​de ambiente que o shell executando qsub (recomendado) A opção - b para qsub declara que o Comando que está sendo executado pode ser um único executável binário ou um script bash. Neste caso, o comando hostname é um único binário. Esta opção leva um argumento y ou n indicando sim o comando é binário ou não, não é um binário. A opção - cwd para qsub diz ao Sun Grid Engine que a tarefa deve ser executada no mesmo diretório que o qsub foi chamado. O último argumento para qsub é o comando a ser executado (hostname neste caso) Observe que o comando qsub, quando bem-sucedido, irá imprimir o número do trabalho para stdout. Você pode usar o número do trabalho para monitorar o status do job8217s e progredir dentro da fila como veremos na próxima seção. Monitorando trabalhos na fila Agora que nosso trabalho foi submetido, let8217s dê uma olhada no status de job8217s na fila usando o comando qstat: A partir desta saída, podemos ver que o trabalho está no estado qw que significa fila e espera . Após alguns segundos, o trabalho será transição para um r. Ou em execução. Estado em que ponto o trabalho começará a ser executado: Uma vez concluído o trabalho, o trabalho será removido da fila e não aparecerá mais na saída do qstat: Agora que o trabalho terminou, vamos passar para a próxima seção para ver Como vemos uma saída de job8217s. Exibindo uma saída de Job8217s O Sun Grid Engine cria arquivos stdout e stderr no diretório de trabalho de job8217s para cada tarefa executada. Se quaisquer arquivos adicionais forem criados durante a execução de um job8217s, eles também estarão localizados no diretório de trabalho do job8217s, a menos que sejam explicitamente salvos em outro lugar. Os arquivos stdout e stderr do job8217s são nomeados após o trabalho com a extensão que termina no número do job8217s. Para o trabalho simples enviado acima, temos: Observe que o Sun Grid Engine automaticamente nomeou o nome do host do trabalho e criou dois arquivos de saída: nome_do_host. e1 e nome_do_host. o1. O e representa stderr eo o para stdout. O 1 no final da extensão files8217 é o número da tarefa. Portanto, se o trabalho tivesse sido nomeado mynewjob e fosse o job 23 submetido, os arquivos de saída seriam parecidos com: Monitoring Cluster Usage 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) ea memória atualmente usada (MEMUSE) e o espaço swap 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 Job Script Na seção 8216Submitting a Job8217 nós enviamos um único hostname de comando. 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 programas / scripts externos: Como você pode ver, este script simplesmente executa alguns comandos (como echo, data, gato, etc.) e sai. 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 de trabalho (ou seja, se instruções, while loops, para loops, etc) e você pode chamar qualquer número de programas externos necessários para concluir o trabalho. Vamos ver como você executa este novo script de trabalho. Salve o script acima para /home/sgeadmin/jobscript. sh no seu StarCluster e execute o seguinte como o usuário sgeadmin: Agora que o trabalho foi submetido, let8217s chamar qstat periodicamente até que o trabalho tenha terminado, uma vez que este trabalho deve ter apenas um segundo Para executar uma vez executado o 8217s: Agora que o trabalho está terminado, let8217s dê uma olhada nos arquivos de saída: Vemos de olhar para a saída que o arquivo stdout contém a saída das instruções echo, date e cat no script de trabalho e Que o arquivo stderr está em branco, significando que não houve erros durante a execução do job8217s. Se algo falhou, como um erro de comando não encontrado, por exemplo, esses erros teriam aparecido no arquivo stderr. Excluindo um trabalho da fila E se um trabalho estiver preso na fila, estiver demorando demais a ser executado ou simplesmente iniciado com parâmetros incorretos Você pode excluir um trabalho da fila usando o comando qdel no Sun Grid Engine. Abaixo vamos lançar um trabalho simples 8216sleep8217 que dorme durante 10 segundos para que possamos matá-lo usando qdel: Depois de executar qdel you8217ll aviso o trabalho é ido da fila: OpenMPI e Sun Grid Engine OpenMPI deve ser compilado com suporte SGE (8211with-sge ) Para fazer uso da estreita integração entre OpenMPI e SGE como documentado nesta seção. Este é o caso em todas as AMIs públicas do StarCluster8217s. O OpenMPI suporta uma integração apertada com o Sun Grid Engine. Essa integração permite que o Sun Grid Engine gerencie a atribuição de hosts a jobs paralelos e a contabilização adequada de jobs paralelos. Ambiente Paralelo OpenMPI Por padrão, o StarCluster configura um ambiente paralelo, chamado 8220orte8221, que foi configurado para integração OpenMPI dentro do SGE e tem um número de slots igual 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 de allocationrule na saída do comando qconf na seção anterior. Isso define como atribuir slots a um job. Por padrão, o StarCluster configura a alocação de 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, mover para a próxima máquina e pegar um único slot, se disponível, e assim por diante envolvendo o cluster novamente, se necessário Para alocar 8 slots para o trabalho. Você também pode configurar o ambiente paralelo para tentar localizar slots o máximo possível usando a regra de alocação de preenchimento. Com essa regra, se um usuário solicitar 8 slots e uma única máquina tiver 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, ele terá todos os 5 nesse host, e todos os 3 no outro host. Em outras palavras, esta regra tomará avidamente todos os slots em um determinado nó até que o requisito de slot para o trabalho seja cumprido. Você pode alternar entre os modos roundrobin e fillup usando o seguinte comando: Isso abrirá vi (ou qualquer editor definido na variável env EDITOR) e permitirá que você edite as configurações do ambiente paralelo. Para mudar de roundrobin para fillup no exemplo acima, altere a linha allocationrule de: Enviando Jobs 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. Executável para o mesmo caminho em todos os nós ou para um local compartilhado NFS no nó mestre É importante que o caminho para o executável seja idêntico em todos os nós para mpirun para lançar corretamente o código paralelo. A abordagem mais fácil é copiar o executável em algum lugar em / home no nó mestre, já que / home é NFS-compartilhado entre todos os nós do cluster. Executar o código no número X de máquinas usando: onde o arquivo de host parece algo como: No entanto, ao usar um ambiente paralelo SGE com 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 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 de preenchimento e roundrobin especificados no ambiente paralelo SGE. Em vez de usar a formulação acima crie um script de trabalho simples que contém uma chamada mpirun muito simplificada: Em seguida, envie o trabalho usando o comando qsub eo ambiente orte paralelo configurado automaticamente para você pelo StarCluster: A opção - pe espécie que ambiente paralelo a usar e Quantos slots para solicitar. O exemplo acima solicita 24 slots (ou processadores) usando o ambiente orte paralelo. O ambiente paralelo cuida automaticamente de distribuir o trabalho MPI entre os nós SGE usando a régua de alocação definida nas configurações do ambiente. Você também pode fazer isso sem um script de trabalho assim: qsub (1) - Linux man page Prolog Esta página de 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 detalhes do comportamento do Linux), ou a interface não pode ser implementada no Linux. Nome qsub - submit a script Sinopse Descrição Para enviar um script é criar um job batch que executa o script. Um script é enviado por uma solicitação 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 job batch que executará o script enviado. O utilitário qsub deve enviar um script enviando um Pedido de Trabalho de Fila para um servidor em lote. O utilitário qsub deve colocar o valor das seguintes variáveis ​​de ambiente no atributo VariableList do trabalho em lote: HOME. LANG. LOGNAME. PATH. MAIL. CONCHA . E TZ. O nome da variável de ambiente deve ser o nome atual prefixado com a seqüência de caracteres PBSO. Nota: Se o valor atual da variável HOME no espaço do ambiente do utilitário qsub for / aa / bb / cc. Então qsub deve colocar PBSOHOME / aa / bb / cc 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 de utilitário qsub. PBSOHOST O nome do host no qual o utilitário qsub está sendo executado. Opções O utilitário qsub deve estar em conformidade com o volume Definições de Base do IEEE Std 1003.1-2001, Seção 12.2, Diretrizes de Sintaxe do Utilitário. As seguintes opções serão suportadas pela implementação: - a datetime Define a hora em que um job de lote se torna 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 de Variáveis ​​de Ambiente (Utilities) Nota: O servidor que inicia a execução do job batch adicionará othervariables ao ambiente de jobs batch, veja Batch Job Execution. O utilitário qsub deve definir o atributo ExecutionTime do job batch para o número de segundos desde que o Epochthat é equivalente à hora local expressa pelo valor da opção datetime-argumento. A Epoch é definida no volume Definições de IEEE Std 1003.1-2001, Seção 3.149, Epoch. Operandos Arquivos de entrada Stdin Variáveis ​​de ambiente Eventos assíncronos Submeter seu conteúdo de trabalho em lote Como enviar um trabalho em lote Os trabalhos em lote não interativos são enviados com o comando qsub. A forma geral do comando é: Por exemplo, para enviar o comando printenv ao sistema batch, execute: A opção - b y indica ao sistema batch 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 job estiver em execução, o sistema batch cria arquivos stdout e stderr no diretório de trabalho do job8217s, nomeados após o trabalho com a extensão que termina no número job8217s, para o exemplo acima printenv. o jobID e printenv. e jobID. O primeiro conterá a saída do comando e o segundo terá a lista de erros, se houver, que ocorreram enquanto o job estava em execução. Ao executar um programa que requer argumentos e passar opções adicionais para o sistema de lote, torna-se rapidamente útil salvá-los em um arquivo de script e enviar esse script como um argumento para o comando qsub. Por exemplo, o seguinte script script. sh 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 em lote, execute: Para procedimentos adicionais de lote MATLAB, consulte Execução do Lote MATLAB no SCC. Diretivas gerais de envio de trabalhos Há várias diretrizes (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 de job. Em um arquivo de script, as linhas que contêm essas diretrizes começam com os símbolos 8211 aqui está um exemplo: Abaixo está a lista de diretrizes mais usadas: O que o qsub faz Visão geral Todos os nossos clusters têm um servidor de lote denominado servidor de gerenciamento de cluster em execução No headnode. Este servidor de lote monitora o status do cluster e controla / monitora as várias filas e listas de tarefas. Empacotado no servidor de lote, um agendador toma decisões sobre como um trabalho deve ser executado e seu posicionamento na fila. Qsub interfaces no servidor de lote e permite que ele saiba que há outro trabalho que solicitou recursos no cluster. Uma vez que um trabalho foi recebido pelo servidor de lote, o agendador decide o posicionamento e notifica o servidor de lote que, por sua vez, notifica qsub (Torque / PBS) se o trabalho pode ser executado ou não. O status atual (se o trabalho foi agendado com êxito ou não) é retornado ao usuário. Você pode usar um arquivo de comando ou STDIN como entrada para qsub. Variáveis ​​de ambiente no qsub O comando qsub passará certas variáveis ​​de ambiente no atributo VariableList da tarefa. Essas variáveis ​​estarão disponíveis para o trabalho. O valor para as seguintes variáveis ​​será retirado do ambiente do comando qsub: Estes valores serão atribuídos a um novo nome, que é o nome atual prefixado com a string quotPBSOquot. Por exemplo, a tarefa terá acesso a uma variável de ambiente denominada PBSOHOME que possui o valor da variável HOME no ambiente de comando qsub. Além dessas variáveis ​​de ambiente padrão, existem variáveis ​​de ambiente adicionais disponíveis para o trabalho. PBSOHOST (o nome do host em que o comando qsub está sendo executado) PBSOQUEUE (o nome da fila original para a qual o trabalho foi enviado) PBSOWORKDIR (o caminho absoluto de O diretório de trabalho atual do comando qsub) PBSARRAYID (cada membro de uma matriz de trabalho é atribuído um identificador exclusivo) PBSENVIRONMENT (definido como PBSBATCH para indicar o trabalho é um trabalho em lotes ou PBSINTERACTIVE para indicar o trabalho é um trabalho interativo PBS) PBSJOBNAME (o nome do trabalho fornecido pelo usuário) PBSJOBNAME (o nome do arquivo contém a lista de nós atribuídos ao trabalho) PBSQUEB (o nome da fila a partir do qual) O trabalho foi executado a partir de) PBSWALLTIME (o walltime solicitado pelo usuário ou walltime padrão atribuído pelo agendador) Argumentos para controlar o comportamento Como dito antes, existem vários argumentos que você pode usar para obter seus postos de trabalho de forma específica. Esta não é uma lista exaustiva, mas alguns dos mais amplamente utilizados e muitos que você provavelmente vai precisar para realizar tarefas específicas. Declarar a data / hora em que um trabalho se torna elegível para execução Para definir a data / hora em que um trabalho se torna elegível para execução, use o argumento - a. O formato de data / hora é CCYYMMDDhhmm. SS. Se - a não for especificado qsub assume que o job deve ser executado imediatamente. Exemplo Para testar - a obter a data atual a partir da linha de comando e adicionar um par de minutos para ele. Ele foi 10:45 quando a I xadrezes. Adicione hhmm a - a e envie um comando do STDIN. Exemplo: Definir a data / hora em que um trabalho se torna elegível para execução Isso mostra que os números são gravados para output. txt. O que, por sua vez, mostra que os trabalhos funcionaram um após a conclusão bem sucedida de outro. Abrindo um shell interativo para o nó de computação Para abrir um shell interativo para um nó de computação, use o argumento - I. Exemplo: Abra um shell interativo para um nó de computação Passando uma variável de ambiente para o seu trabalho Você pode passar variáveis ​​de ambiente definidas pelo usuário para Um trabalho usando o argumento - v. Exemplo Para testar isso, usaremos um script simples que imprime uma variável de ambiente. Passando uma variável de ambiente Depois que o shell é aberto, use o comando env para ver que seu ambiente foi passado para o trabalho corretamente. Você ainda deve ter acesso a todos os módulos que você carregou anteriormente. Submeter um trabalho de matriz: Gerir grupos de tarefas Por vezes, os utilizadores pretendem enviar um grande número de trabalhos com base no mesmo script de trabalho. Em vez de usar um script para chamar repetidamente qsub, existe um recurso conhecido como array de trabalho para permitir a criação de vários jobs com um comando qsub. Além disso, esse recurso inclui uma nova convenção de nomenclatura de tarefas que permite aos usuários fazer referência ao conjunto inteiro de tarefas como uma unidade ou para fazer referência a um trabalho específico do conjunto. Cada trabalho enviado terá um id de trabalho no formato ltidgtltnumgt. hostname. No caso de um número de submissão de 5554444, cada job 5554444x tem uma variável de ambiente denominada PBSARRAYID, que é definida como o valor do índice de matriz da tarefa, portanto 55544440.hostname teria PBSARRAYID definido como 0. Isso permitirá que você Crie matrizes de trabalho onde cada trabalho na matriz executará ações ligeiramente diferentes com base no valor dessa variável, como executar as mesmas tarefas em arquivos de entrada diferentes. Outra diferença no ambiente entre os trabalhos na mesma matriz é o valor da variável PBSJOBNAME. Exemplo Primeiro precisamos criar dados para serem lidos. Observe que, em um aplicativo real, isso pode ser dados, configuração ou qualquer coisa que seu programa precise executar. Criar dados de entrada Para criar dados de entrada, execute este simples recorte: Criando dados de entrada