Por que apenas metade dos núcleos no meu servidor linux hyperthreaded seria carregado?

2

Eu tenho um servidor que é um sistema hyperthreaded de 12 núcleos, o que significa que eu tenho 24 núcleos virtuais.

Estou executando 24 processos no meu servidor, cada um escutando em sua própria porta e fazendo as mesmas coisas, embora de diferentes clientes e solicitações diferentes. O processo é um script python que foi criado usando gevent para simultaneidade enquanto aguarda a conclusão das operações de rede. top e htop mostram cada um dos processos usando aproximadamente o mesmo CPU e memória. Como estou executando o mesmo número de processos que os núcleos, eu esperaria que todos os núcleos fossem carregados da mesma forma. No entanto, estou vendo apenas metade dos núcleos tendo alguma carga real sobre eles (o restante mostra uma carga mínima).

O que é mais estranho para mim é que são sempre os mesmos núcleos, 6-11 e 18-23. Além do mais, eu tenho três dos mesmos servidores fazendo sobre a mesma coisa e sob a mesma carga e todos os 3 estão usando os mesmos núcleos em aproximadamente a mesma carga. Alguém sabe por que isso seria?

Aqui está a saída do sar de um desses servidores:

04:34:01 PM     CPU     %user     %nice   %system   %iowait    %steal     %idle
04:35:01 PM     all     18.67      0.00      3.65      0.01      0.00     77.68
04:35:01 PM       0      9.24      0.00      0.76      0.00      0.00     89.99
04:35:01 PM       1      3.16      0.00      0.55      0.00      0.00     96.30
04:35:01 PM       2      1.40      0.00      0.66      0.00      0.00     97.94
04:35:01 PM       3      0.46      0.00      0.12      0.00      0.00     99.42
04:35:01 PM       4      0.15      0.00      0.12      0.00      0.00     99.73
04:35:01 PM       5      0.35      0.00      0.81      0.00      0.00     98.84
04:35:01 PM       6     44.19      0.00     10.05      0.02      0.00     45.74
04:35:01 PM       7     43.99      0.00     10.84      0.02      0.00     45.15
04:35:01 PM       8     27.00      0.00      2.57      0.09      0.00     70.33
04:35:01 PM       9     40.91      0.00      9.02      0.02      0.00     50.06
04:35:01 PM      10     41.97      0.00     10.27      0.00      0.00     47.77
04:35:01 PM      11     33.52      0.00      5.26      0.02      0.00     61.21
04:35:01 PM      12      0.53      0.00      0.10      0.00      0.00     99.37
04:35:01 PM      13      0.32      0.00      0.08      0.00      0.00     99.60
04:35:01 PM      14      0.22      0.00      0.10      0.00      0.00     99.68
04:35:01 PM      15      0.13      0.00      0.10      0.00      0.00     99.77
04:35:01 PM      16      0.12      0.00      0.05      0.00      0.00     99.83
04:35:01 PM      17      0.13      0.00      0.30      0.00      0.00     99.57
04:35:01 PM      18     16.54      0.00      1.49      0.00      0.00     81.97
04:35:01 PM      19     36.16      0.00      5.85      0.02      0.00     57.98
04:35:01 PM      20     29.22      0.00      4.97      0.10      0.00     65.71
04:35:01 PM      21     32.86      0.00      5.25      0.02      0.00     61.87
04:35:01 PM      22     43.01      0.00      9.19      0.00      0.00     47.80
04:35:01 PM      23     39.63      0.00      8.61      0.02      0.00     51.74

E aqui está a saída de / proc / cpuinfo para um dos núcleos:

processor       : 23
vendor_id       : GenuineIntel
cpu family      : 6
model           : 44
model name      : Intel(R) Xeon(R) CPU           X5675  @ 3.07GHz
stepping        : 2
cpu MHz         : 1600.000
cache size      : 12288 KB
physical id     : 1
siblings        : 12
core id         : 10
cpu cores       : 6
apicid          : 53
initial apicid  : 53
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2 popcnt lahf_lm ida arat tpr_shadow vnmi flexpriority ept vpid
bogomips        : 6133.17
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management:

Esses sistemas também têm ~ 24GB de RAM, dos quais menos de 4GB estão sendo usados, e não mostram nenhuma atividade de troca. Também há muito pouca atividade de disco, quase tudo o que esses servidores fazem é vinculado à rede, cerca de 60-80MB / s cada, entradas e saídas de placas Gigabit Ethernet, ligadas a uma única interface.

    
por papercrane 19.09.2011 / 23:45

2 respostas

1

Isto é porque é um servidor hyperthreaded. Metade dos processadores são apenas "virtuais". Então o Linux tenta evitar essas CPUs virtuais e se concentrar nas reais.

Como seu sistema não está sob carga, você não pode ver que os outros serão usados em uma carga maior. Experimente e aumente a carga. Você vai ver a diferença.

    
por 20.09.2011 / 00:00
3

Núcleos com hyperthreaded não devem ser tratados como núcleos totalmente capazes. Lembre-se, eles são núcleos virtuais, então eles compartilham alguns dos recursos dos núcleos físicos. O benefício de hyperthreading superfícies em processos altamente segmentados e paralelizados, mas não no caso de uso que você está descrevendo. Na minha experiência, os núcleos hyperthreaded funcionam como 30-40% de um núcleo real, então eu costumo impedir que coisas importantes sejam executadas neles. Se você espera um processo um para um para o mapeamento central, talvez seja melhor ligar 12 processos aos núcleos reais ou evitar os núcleos virtuais ao desabilitar o hyperthreading ou a blindagem da CPU.

Você está usando algum tipo de mapeamento de afinidade de CPU (conjunto de tarefas, cset) ou apenas deixando o Linux lidar com as atribuições? Em caso afirmativo, o que você está vendo é o melhor uso da sua situação pelo agendador, preferindo núcleos reais de núcleos virtuais.

    
por 20.09.2011 / 00:04