Determine qual servidor é a melhor escolha para tarefas que consomem muitos recursos

4

Eu tenho uma tarefa que consome tempo e recursos que estou executando de vez em quando ( make ), que pode ser executada em qualquer um de um pool de servidores.

O problema é que eu não sou o único usuário que está executando make , e quando dois ou mais usuários inconscientes executam make simultaneamente, leva uma eternidade, e algumas vezes o servidor até falha. Então, decidimos que sempre que alguém quiser executar make , ele deve primeiro ssh em um dos servidores, certifique-se de que make ainda não esteja sendo executado por outro usuário (usando w do linux) e só então ele começa make .

Em minhas tentativas de automatizar o processo de escolha de um servidor, escrevi um script simples, que faz um loop no pool de servidores, ssh em cada um deles e escolhe o primeiro servidor para o qual a saída de w não tem make , mas essa abordagem é muito ingênua porque ignora o seguinte:

  • Cada servidor tem atributos diferentes (por exemplo, um com 12 CPUs e o outro com 80 CPUs)
  • make não é a única tarefa que esses servidores executam
  • w mostra apenas processos de usuários que estão logados através de ssh , e enquanto make é executado usando ssh na maioria das vezes, pode ser que alguém esteja executando make do próprio servidor.

Eu quero alterar os critérios para escolher um servidor, mas não tenho certeza do que deveria ser.
Procurei on-line e encontrei o comando top , mas, novamente, não tenho certeza do que deve ser considerado.
Por exemplo, pensei em usar os critérios: $(top -bn 1 | grep 'Cpu\(s\)' | gawk '{print $2+$3+$4+$6+$7+$8}') para determinar qual é o menos movimentado no momento, mas isso ignora os atributos do servidor. Poderia haver um servidor mais ocupado com muito mais CPUs.

    
por so.very.tired 28.05.2016 / 10:45

1 resposta

0

Você deve procurar por um agendador de tarefas / tarefas, um sistema de gerenciamento de clusters ou um gerenciamento de nuvem distribuídos. Muitos destes já existem; cas apontou para vários em seus comentários e o Google vai aparecer muito mais.

Suspeito que todos vocês ficarão muito mais felizes quando você tiver implantado um e não precisar mais se preocupar em pisar nos dedos uns dos outros o tempo todo. Além disso, você deve consertar seus servidores para que os erros façam com que a tarefa falhe, e não derrubem a máquina.

Se você insistir em construir o seu próprio (algo que confesso ter feito - embora tenha sido há 15 anos), as tarefas em geral consomem vários tipos diferentes de recursos, e você provavelmente quer considerar quais são suas tarefas:

  • memória (RAM) [do seu vai muito lento ou falha, eu acho que isso é um grande problema para sua tarefa make ]
  • largura de banda de E / S de disco
  • operações de E / S de disco por segundo (pesquisas)
  • espaço em disco
  • Tempo de CPU
  • tempo da GPU
  • largura de banda de rede

Você pode verificar o uso de memória via free , E / S de disco via iostat , espaço com free , uso da CPU via cat /proc/loadavg (no Linux) ou uptime , top , ps , etc.

Mas, é claro, verificar os números atuais tem um problema - talvez seu trabalho make primeiro faça algumas coisas simples, levando alguns minutos, e então dispara o enorme processo que leva a RAM. Isso pode acontecer:

  1. Alice executa o script para iniciar uma tarefa "make".
  2. O script verifica o serverA, vê que ele tem toneladas de RAM livre, baixo uso da CPU e inicia a tarefa no serverA.
  3. Pouco tempo depois, Bob executa o script para iniciar outra tarefa que exige muito da RAM.
  4. A tarefa de Alice ainda não chegou à fase de uso intensivo de recursos. Então, quando o script verifica o serverA, ele ainda tem toneladas de RAM livre. Inicia a tarefa de Bob no serverA também.
  5. A tarefa de Bob consome a maior parte da RAM livre no servidorA
  6. A tarefa de Alice finalmente chega à parte de uso intensivo de RAM, mas não há RAM disponível agora. Uh-oh! ServerA se debate até a morte.

Sim, o texto acima vem da experiência de escrever um (embora para o que eu estava usando o meu, era o tempo de CPU).

    
por 03.06.2016 / 20:00

Tags