Como todos sabemos, a carga de 1,00 em um único processador significa que há uma carga de 100% . Analogamente, uma carga de 4,00 em um quad core seria 100% .
Como devo interpretar a carga em um processador de 4 núcleos e 8 threads? Quando alcanço a capacidade máxima da CPU? Às 4,00 ou 8,00 ?
Respostas:
Não certamente, mas principalmente por diante 1.00*n_cpu.
A carga significa o seguinte: se houver vários processos em um sistema de uma única CPU, eles estão executando aparentemente paralelos. Mas isso não é verdade. O que praticamente acontece: o kernel dá 1/100 de segundo a um processo e depois interrompe sua execução com uma interrupção. E dá o próximo 1/100 de segundo para outro processo.
Praticamente a questão "qual processo deve receber nosso próximo intervalo de 1/100 de segundo?" Será decidida por uma heurística complexa. É nomeado como agendamento de tarefas .
Obviamente, os processos bloqueados, por exemplo, estão aguardando seus dados pelo que estão lendo no disco, estão isentos desse agendamento de tarefas.
O que diz a carga: quantos processos estão aguardando o próximo período de 1/100 de segundo. Claro, é um valor médio. Isso ocorre porque você pode ver vários números em a cat /proc/loadavg.
A situação em um sistema com várias CPUs é um pouco mais complexa. Existem várias CPUs, cujos prazos podem ser atribuídos a vários processos. Isso torna o agendamento de tarefas um pouco - mas não muito - mais complexo. Mas a situação é a mesma.
O kernel é inteligente, tenta compartilhar os recursos do sistema para obter a eficiência ideal, e é quase isso (existem pequenas coisas de otimização, por exemplo, é melhor que um processo seja executado o maior tempo possível no mesmo CPU devido a considerações de cache, mas elas não são importantes lá). Isso ocorre porque, se tivermos carga 8, isso significa: na verdade, existem 8 processos aguardando sua próxima fatia de tempo. Se tivermos 8 cpus, podemos atribuir esses intervalos de tempo ao cpus um a um e, portanto, nosso sistema será usado de maneira ideal.
Se você vir um top, poderá ver que o número de processos em execução reais é surpreendentemente baixo: eles são os processos marcados por Rlá. Mesmo em um sistema não muito rígido, ele geralmente fica abaixo de 5. Isso ocorre parcialmente porque os processos que aguardam seus dados dos discos ou da rede também estão suspensos (marcados com Sna parte superior). A carga mostra apenas o uso da CPU.
Também existem ferramentas para medir a carga do disco, que devem ser pelo menos importantes como o monitoramento do uso da CPU, mas de alguma forma não é tão conhecido aqui em nosso mundo profissional de administrador de sistemas.
As ferramentas do Windows geralmente dividem a carga com o número real dos cpus. Isso faz com que alguns administradores de sistema profissionais do Windows usem a carga do sistema nesse sentido dividido por CPU. Eles não estão certos e provavelmente ficarão mais felizes depois que você explicar isso a eles.
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 com hyperthread mais lentos. Mas isso acontece em uma camada mais profunda com a qual o agendamento de tarefas normal lida, embora possa (e deva) influenciar as decisões de mudança de processo do agendador.
Mas do nosso ponto de vista atual - o que determina a carga do sistema - isso não importa também.
Como o hyperthreading não é realmente um segundo núcleo, nunca levará um núcleo para 200%, mas levará além de 100% para determinadas cargas de trabalho.
Portanto, sua carga máxima é algo desconhecido entre aproximadamente 4 e 6
(é claro que isso pode aumentar mais quando sobrecarregado, porque na verdade conta processos executáveis, principalmente quando eles estão aguardando IO)
A média de carga não significa o que você pensa que significa. Não se trata do uso instantâneo da CPU, mas de quantos processos estão aguardando para serem executados. Geralmente, isso ocorre devido a muitas coisas que desejam CPU, mas nem sempre. Um culpado comum é um processo aguardando IO - disco ou rede.
Tente executar ps -e ve procurar 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").
Como é da página de psmanual, você encontra mais detalhes lá - Re os Dprocessos provavelmente são de particular interesse.
Você pode acabar com 'picos' de carga médios por todos os tipos de razões, para que eles não sejam realmente uma boa medida de algo além de 'esse sistema está ocupado'. Ficar atolado no mapeamento da carga média dos núcleos da CPU não vai fazer nenhum bem.
Fiz algumas experiências em nosso sistema Xeon de 24 núcleos (2 soquetes 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 recebe 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 for de 24,0. Em seguida, você obtém uma taxa de transferência adicional de cerca de 10% para os 24 processadores lógicos restantes (a carga é executada em 48,0). Outra maneira de pensar é que, se você executar 48 threads nos 24 núcleos, receberá um aumento de 10 a 20% se ativar o hyperthreading em vez de não. Não é um aumento de 100% como o pessoal de marketing implicaria.
Por exemplo, uma maneira de testar essa observação é ter um processo que executa 48 threads (por exemplo, usando TBB ou modelo de encadeamento manual) e, em seguida, execute
time numactl --physcpubind=0-23 ./myprocess
e depois corra
time numactl --physcpubind=0-47 ./myprocess
O último deve ser executado em cerca de 10 a 20% menos tempo. Se o seu processo estiver altamente bloqueado de E / S, o resultado poderá ser diferente.
O primeiro desativará o hyperthreading, permitindo apenas que os threads sejam executados em um único processador lógico (de cada núcleo), enquanto o último ativará o hyperthreading, permitindo que os threads sejam executados em 2 processadores lógicos (de cada núcleo).
A carga nos dois casos deve ser relatada como 48,0 ... o que, como você pode ver, é muito enganador.