Maneira apropriada de interpretar a carga do sistema em um processador de 8 threads de 8 núcleos

Question

Como todos sabemos, o carregamento de 1,00 em um único processador significa que há uma carga de 100% . Analogicamente, uma carga 4.00 em um quad core seria 100% .

Como devo interpretar a carga em um processador de 8 núcleos de 4 núcleos? Quando alcanço a capacidade máxima da CPU? Em 4.00 ou 8.00 ?

    

Answer 1

Não com certeza, mas principalmente em 1.00*n_cpu .

A carga significa o seguinte: se houver vários processos em um sistema de CPU única, eles estarão executando aparentemente paralelos. Mas isso não é verdade. O que praticamente acontece: o kernel fornece 1/100 segundo para um processo e, em seguida, interrompe sua execução com uma interrupção. E dá o próximo 1/100 segundo para outro processo.

Praticamente a pergunta "qual processo deve obter o próximo intervalo de 1/100 segundos?", será decidida por uma heurística complexa. É nomeado como tarefa agendamento .

Naturalmente, processos que são bloqueados, por exemplo, eles estão esperando seus dados o que eles estão lendo do disco, estão isentos deste agendamento de tarefas.

O que a carga diz: quantos processos estão atualmente aguardando seu próximo 1/100 segundo tempo. Claro, é um valor médio. Isso porque você pode ver vários números em um cat /proc/loadavg .

A situação em um sistema multi-cpu é um pouco mais complexa. Existem vários processadores, cujos intervalos de tempo podem ser fornecidos para vários processos. Isso torna o agendamento de tarefas um pouco - mas não muito - complexo. Mas a situação é a mesma.

O kernel é inteligente, ele tenta compartilhar os recursos do sistema para a eficiência ideal, e está próximo disso (existem pequenas coisas de otimização, por exemplo, é melhor se um processo for executado o maior tempo possível no mesmo cpu por causa de considerações de cache, mas não importa lá). Isso porque, se tivermos carga 8, isso significa: na verdade, há oito processos aguardando o próximo intervalo de tempo. Se tivermos 8 processadores, podemos dar essas fatias de tempo para o processador de um para um e, assim, nosso sistema será usado de maneira ideal.

Se você vir um top , verá que o número dos processos em execução reais é surpreendentemente baixo: eles são os processos marcados por R . Mesmo em um sistema não muito hardcore, é geralmente abaixo de 5. Isso ocorre parcialmente porque os processos aguardando seus dados dos discos ou da rede também são suspensos (marcados com S no topo). A carga mostra apenas o uso da CPU.

Também há ferramentas para medir a carga do disco, pelo que elas devem ser pelo menos importantes como o monitoramento do uso da CPU, mas de alguma forma isso não é tão conhecido aqui em nosso mundo sysadmin profissional.

As ferramentas do Windows geralmente dividem a carga com o número real dos processadores. Isso faz com que algum administrador profissional do sistema windows use o carregamento do sistema nesse sentido dividido por cpu. Eles não têm razão e provavelmente serão mais felizes depois que você explicar isso para eles.

As CPUs Multicore são praticamente múltiplas CPUs no mesmo chip de silício. Não há diferença.

No caso de CPUs com hyperthread, há um efeito colateral interessante: carregar uma cpu torna seus pares hyperthreaded mais lentos. Mas isso acontece em uma camada mais profunda do que o agendamento normal de tarefas manipula, embora possa (e deva) influenciar as decisões de movimentação de processos do agendador.

Mas do ponto de vista atual - o que determina a carga do sistema - isso também não importa.

    

Answer 2

Como o hyperthreading não é realmente um segundo núcleo, ele nunca levará um núcleo a 200%, mas levará além de 100% para determinadas cargas de trabalho.

Portanto, sua carga máxima é desconhecida entre aproximadamente 4 e 6

(é claro que isso pode aumentar quando sobrecarregado, porque na verdade conta processos executáveis, particularmente quando eles estão esperando pelo IO)

    

Answer 3

A média de carga não significa o que você acha que significa. Não se trata de uso instantâneo da CPU, mas de quantos processos estão aguardando para serem executados. Geralmente é por causa de muitas coisas que querem CPU, mas nem sempre. Um culpado comum é um processo aguardando um disco de E / S ou uma rede.

Tente executar ps -e v e procurando por sinalizadores de estado do processo.

state    The state is given by a sequence of characters, for example, "RWNA". The      first character indicates the run state of the process:
D    Marks a process in disk (or other short term, uninterruptible) wait.
I    Marks a process that is idle (sleeping for longer than about 20 seconds).  
L    Marks a process that is waiting to acquire a lock.
R    Marks a runnable process.
S    Marks a process that is sleeping for less than about 20 seconds.
T    Marks a stopped process.
W    Marks an idle interrupt thread.
Z    Marks a dead process (a "zombie").

Isso é da% man_de% manpage, para que você encontre mais detalhes - ps e R processos são provavelmente de interesse particular.

Você pode acabar com picos médios de carga por todos os tipos de motivos, então eles não são realmente uma boa medida de outra coisa senão "é este sistema ocupado-ish". Ficar atolado na média de carga de mapeamento para os núcleos da CPU não fará nenhum bem a você.

    

Answer 4

Em um sistema Linux, não apenas os processos na fila executável são contados para calcular a carga, mas também aqueles em estados de suspensão ininterruptos, wikipedia , fazendo com que a carga aumente quando você tem muitos processos esperando pelo disco.

    

Answer 5

Eu fiz algumas experiências no nosso sistema Xeon de 24 núcleos (2 soquete x 12 núcleos). A carga máxima é 48.0 neste caso devido à maneira como o Linux configura o hyperthreading.

No entanto, você não obtém o equivalente a 48 núcleos de taxa de transferência. O que observei é que você obtém cerca de 90% da taxa de transferência nos primeiros 24 processadores lógicos, ou seja, se a carga chegar a 24.0. Em seguida, você obtém uma taxa de transferência adicional de cerca de 10% para os 24 processadores lógicos restantes (carregamento executado em 48.0). Outra maneira de pensar sobre isso é que, se você executar 48 threads nos 24 núcleos, obterá um aumento de cerca de 10-20% se habilitar o hyperthreading versus não. Não é um aumento de 100%, como os caras de marketing implicariam.

Por exemplo, uma maneira de testar essa observação é ter um processo que executa 48 threads (digamos, usando TBB ou modelo de segmentação manual) e, em seguida, execute

time numactl --physcpubind=0-23  ./myprocess

e, em seguida, execute

time numactl --physcpubind=0-47  ./myprocess

O último deve ser executado em cerca de 10 a 20% menos tempo. Se o seu processo for altamente bloqueado por E / S, o resultado poderá ser diferente.

O primeiro desabilitará o hyperthreading permitindo que os encadeamentos sejam executados em um único processador lógico (de cada núcleo), enquanto o segundo ativará o hyperthreading permitindo que os encadeamentos sejam executados em 2 processadores lógicos (de cada núcleo).

A carga em ambos os casos deve ser relatada como 48.0 ... o que, como você pode ver, é muito enganador.