faz nohup colocar cada processo em um núcleo especificamente

0

Eu estava lendo esse link agora e isso me fez pensar.

Há algum tempo eu estava lançando simulações em até 30 núcleos de uma VM 32core, e estava fazendo isso com um script de invólucro que chamava nohup perl ...<rest of command>... e redirecionava o STOUT / STDERR - não tenho certeza se os detalhes são relevantes , então eu vou poupar os detalhes.

Estou conceitualmente feliz com tarefas multiencadeadas, mas ingenuamente simplesmente presumi que basear cada processo em minha chamada nohup (cada processo era uma simulação separada que era executada por várias semanas) era suficiente para colocar cada processo filho em um núcleo / thread próprio e, em seguida, apenas seguir para a conclusão, sem apelar para o GNU Parallels ou algo assim.

Eu verifiquei sobre eles periodicamente, e sempre vi que 30 vCPUs estavam trabalhando nas tarefas, tudo concluído em tempo razoável para que nada parecesse errado com a minha lógica até agora ...

Alguém (eu acho que em uma página SO em algum lugar) me disse que isso pode acabar causando "thrashing CPU".

Então, minha pergunta tem algumas partes inter-relacionadas:

  • Primeiramente, eu estava errado em assumir que nohup e / ou background é suficiente para colocar um processo em um núcleo específico? (E o processo que está sendo executado em um núcleo específico pode ser exibido no terminal? O Top apenas informa quais núcleos estão ocupados, não quais tarefas estão executando até onde eu sei?)
  • Em segundo lugar, a sobrecarga da CPU ocorrerá mesmo se houver duas CPUs sobressalentes disponíveis para lidar com as outras tarefas do sistema?
  • Por último, se eu não estivesse errado, um determinado processo seria fixado em uma CPU específica, e apenas nessa CPU , ou eles iriam alternar entre as threads dependendo da ordem / data da chamada, etc. ou seja, se eu passar os arquivos em loop, o primeiro será fixado na CPU 0, depois em 1, 2 e assim por diante até a conclusão?
por Joe Healey 26.10.2016 / 22:58

2 respostas

2

nohup não define nada para manter um processo em um núcleo específico. Você normalmente usa taskset junto com nohup para fazer isso. top pode mostrar em qual núcleo um processo foi agendado pela última vez, é a coluna P .

O agendamento de processos e threads cresceu bastante ao longo dos anos, porque há cada vez mais fatores a serem levados em conta: afinidade de CPU, afinidade de cache, manipulação de interrupções, envelopes de energia ... Mas eu não esperaria nenhuma surra se você está iniciando menos trabalhos do que os núcleos disponíveis, supondo que o sistema não esteja muito ocupado com outras tarefas. De maneira semelhante, você não pode realmente prever em qual CPU uma tarefa será executada, mas se for apropriada, é muito provável que o agendador a mantenha no mesmo núcleo assim que for escolhido um núcleo.

    
por 26.10.2016 / 23:12
3

Firstly, was I wrong to assume nohup and/or backgrounding is process that's running on a specific core be displayed in terminal? Top only tells you which cores are busy, not what task they're executing to my knowledge?)sufficient to stick a process on a particular core? (And can the

Nohup executa o comando exatamente como se eles fossem executados sem, apenas a diferença é que eles são removidos de uma lista de pids para enviar um sinal para a saída. (negar obras para o processo não iniciado com nohup).

Secondly, will CPU thrashing occur even if there are 2 spare CPUs available to handle the systems other tasks?

Somente se a espancamento de CPU ocorrer sem nohup ...

Lastly, if I wasn't wrong, does a given process get pinned to a specific CPU, and only that CPU, or will they jump around between threads depending on call order/timing etc. i.e. if I looped over files, will the first one get pinned to CPU 0, then 1, 2 and so on until completion?

mesmo que sem nohup ...

você pode ver em qual núcleo da cpu um processo está sendo executado com ps, e você pode limitar ou alterar os limites nos núcleos usando o taskset.

ps -eo pid,sgi_p,cmd --sort sgi_p

taskset -c -p 0 1234
    
por 26.10.2016 / 23:11