Processos Python aparecendo e desaparecendo no topo

Question

Eu já lancei cerca de 12 scripts Python em um servidor de 24 núcleos (Ubuntu 14.04 LTS x64). Cada script Python leva cerca de uma hora para ser concluído.

Eu vejo no topo que eles aparecem esporadicamente, enquanto cada script deve ter pelo menos 100% de um núcleo sem interrupção (não há disco IO envolvido, nenhum IO de rede e nenhuma troca desde que o servidor tenha 100 GB de RAM e os requisitos de RAM de script são bastante leves):

O que pode explicar que, no topo, cada script não ocupa 100% da CPU para um núcleo ou mais?

O servidor de 24 núcleos faz parte de um cluster de computador, mas normalmente, se houver alguma sobrecarga, o st no topo explicaria isso. (ou seja, ser muito mais do que 0,0).

    

Answer 1

Eu estou supondo que seu kernel não os veja como prioritários:)

Se você der uma olhada na sua imagem, poderá ver que os processos do Python têm uma prioridade de 20. Esse é o valor padrão. Isso significa que, se deixarmos de lado outros fatores de planejamento (tempo de CPU já alocado, estado do processo, ...), seus scripts Python serão considerados tão importantes quanto top , rcu_shed , sshd , ... Agora , embora esses processos nem sempre tenham coisas para fazer, eles ainda têm acesso à CPU sempre que entram no diretório RUNNING estado .

Os processos do Linux são executados em quantums de tempo (ou fatias de tempo). Isso significa que a cada n milissegundos, o kernel antecipa (suspende) o processo atualmente em execução (em um núcleo) e procura por outro processo a ser planejado. Por padrão, o valor da fatia de tempo é de 100 ms ( ou assim ).

Como sua máquina tem 24 núcleos, basicamente você pode supor que 24 processos podem ser programados para serem executados simultaneamente. Os processos (24) que são selecionados (a cada 100 ms) para agendamento são escolhidos com base em vários fatores. Além disso, um processo também pode ser antecipado se entrar em um estado adormecido antes que sua fatia de tempo expire. A partir do Linux 2.6, o kernel usa o algoritmo Completely Fair Scheduler por padrão. A prioridade de agendamento de processos é baseada principalmente no tempo que cada processo já passou executando e leva em consideração a "prioridade do usuário" (niceness) através de um fator de decaimento :

CFS doesn't use priorities directly but instead uses them as a decay factor for the time a task is permitted to execute. Lower-priority tasks have higher factors of decay, where higher-priority tasks have lower factors of delay. This means that the time a task is permitted to execute dissipates more quickly for a lower-priority task than for a higher-priority task. That's an elegant solution to avoid maintaining run queues per priority.

Agora, é possível (de userland) executar um processo com um valor de niceness personalizado por meio do comando nice :

nice [OPTION] [COMMAND [ARG]...]
    Run  COMMAND  with an adjusted niceness, which affects  process scheduling. 
    With no COMMAND, print the  current niceness. Niceness  values range  from 
    -20 (most favorable to the process) to 19 (least favorable to the process).

Tenha em mente que o escalonador do Linux não usa essa prioridade como algo absoluto. Este valor será levado em conta sempre que o kernel precisar selecionar um processo, mas outros fatores também serão levados em conta: a ganância de seus processos torna muito menos provável que sejam selecionados de qualquer maneira _{(o nome do algoritmo é bastante auto- explicativo sobre isso: p)} .