% CPU para um processo

Question

Olhando para a saída do topo em nosso servidor, um de meus colegas me disse que o fato de alguns processos terem menos de 100% de "CPU" era porque eu estava executando muitos processos. Ele acrescentou que, com base em sua experiência, se eu executar menos de 6 processos, provavelmente todos os processos teriam 100% de "CPU".

Eu não quero ser um aborrecimento para outros usuários, mas duvido que o que ele disse está correto. O servidor tem 16 núcleos e a média de carga atual está entre 10 e 11. Pelo que aprendi, ele não está sobrecarregado. Mas eu não sei porque alguns processos estão recebendo menos de 100 "% de CPU"? É realmente por minha causa?

Obrigado e cumprimentos!

Aí vem a saída do topo:

top - 16:34:13 up 32 days,  1:36, 12 users,  load average: 10.61, 10.39, 10.22
Tasks: 380 total,  10 running, 370 sleeping,   0 stopped,   0 zombie
Cpu(s): 55.0%us,  1.7%sy,  0.0%ni, 42.2%id,  0.5%wa,  0.1%hi,  0.4%si,  0.0%st
Mem:  130766620k total, 39859784k used, 90906836k free,   849412k buffers
Swap: 47351548k total,   279456k used, 47072092k free, 19792956k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                        
17197 tim    18  -2 1315m 1.3g 1504 R  100  1.0   4510:11 MLtest                                                                                       
28762 tim    18  -2 1315m 1.3g 1504 R  100  1.0   4633:01 MLtest                                                                                       
29249 tim    18  -2 1315m 1.3g 1504 R  100  1.0   4623:03 MLtest                                                                                       
29560 tim    18  -2 1315m 1.3g 1504 R  100  1.0   4626:59 MLtest                                                                                       
 4904 tim    18  -2 1315m 1.3g 1504 R  100  1.0   4757:12 MLtest                                                                                       
 5143 tim    18  -2 1315m 1.3g 1504 R  100  1.0   4759:40 MLtest                                                                                       
29389 tim    18  -2 1315m 1.3g 1504 R   99  1.0   4622:11 MLtest                                                                                       
 5285 tim    18  -2 1315m 1.3g 1504 R   97  1.0   4758:49 MLtest                                                                                       
 4763 tim    18  -2 1315m 1.3g 1504 R   93  1.0   4754:22 MLtest                                                                                       
 9456 zma    18  -2  206m  85m  11m S   48  0.1  60:46.78 dropbox                                                                                         
 7527 vals   18  -2 1266m 436m  42m S    4  0.3 613:57.10 MATLAB                                                                                          
 2903 root   15  -5     0    0    0 S    1  0.0  19:00.01 rpciod/0                                                                                        
19133 vals   18  -2 1380m 503m  42m S    1  0.4 798:47.99 MATLAB                                                                                          
12454 tim    18  -2 19248 1588 1024 R    1  0.0   0:48.88 top                                                                                             
   12 root   RT  -5     0    0    0 S    1  0.0  35:01.05 migration/3                                                                                     
 2924 root   15  -5     0    0    0 S    1  0.0  27:20.92 nfsiod                                                                                          
12690 jun    18  -2  913m  84m 2684 S    1  0.1 121:55.65 MATLAB                                                                                          
19650 jun    18  -2 19244 1600 1028 S    1  0.0   6:58.41 top                                                                                             
6 root       RT  -5     0    0    0 S    0  0.0 129:49.45 migration/1                                                                                     
9 root       RT  -5     0    0    0 S    0  0.0 104:34.66 migration/2                                                                                     
 2870 daemon 20   0  8180  404  308 S    0  0.0   5:18.91 portmap                                                                                         
 8985 root   20   0 28484  344  264 S    0  0.0   6:24.77 hald-addon-stor                                                                                 
 9293 root   20   0  369m 4208 2316 S    0  0.0  83:36.35 kdm_greet                                                                                       
24028 tim    18  -2  871m 140m  45m S    0  0.1   7:50.56 MATLAB                                                                                          
1 root      20   0  4104  304  224 S    0  0.0   0:03.59 init
2 root      15  -5     0    0    0 S    0  0.0   0:00.26 kthreadd
3 root      RT  -5     0    0    0 S    0  0.0   0:00.31 migration/0
4 root      15  -5     0    0    0 S    0  0.0   1:08.91 ksoftirqd/0

    

Answer 1

Não sei do que seu amigo está falando, mas parece bem arbitrário e ... bem, claramente errado.

A porcentagem de medida da CPU é um pouco enganosa. Na verdade, qualquer processo que esteja atualmente "ligado" à CPU está recebendo 100% da CPU, naquele momento. A porcentagem refere-se a quanto tempo de CPU esses processos receberam durante a última amostra de tempo.

Portanto, o fato de estarem exibindo menos de 100% de uso da CPU não é uma indicação de um problema.

Uma medida mais relevante em sua saída principal é esta linha: Cpu (s): 55,0% nos, 1,7% sy, 0,0% ni, 42,2% id, 0,5% wa, 0,1% hi, 0,4% si, 0,0% st

Mostra 42% de tempo ocioso na CPU. Portanto, seus outros processos, sejam eles quais forem, não estão ligados à CPU.

    

Answer 2

Os programas fazem mais do que esperar na CPU. Eles esperam no disco uma E / S de rede; eles aguardam a entrada do usuário. Nem todo programa que é executado vai usar 100% da CPU para o quantum de atualização do topo. Por exemplo, quando nada está em execução, você vê init consumindo 100% da CPU? Não.

    

Answer 3

Você pode pressionar "1" (um) e top mostrará as estatísticas da CPU no topo em uma base por CPU. Você pode achar isso informativo.

    

Answer 4

Seu amigo não está apenas errado, mas se você fizer o que ele diz, isso pode muito bem ser contraproducente. Se você tem 16 núcleos e uma carga de 10, você provavelmente deve aumentar o número de processos MLTest que você está executando, se atualmente está limitado a apenas 9 e de alguma forma configurável. Por quê?

Bem, um processo geralmente só pode ser executado em 1 cpu. Se o processo usa 100% da cpu, é cpu ligado. Então, se você restringir e disser que só pode usar 9 processos para fazer o que o MLTest faz, então você só pode usar 9 desses 16 processadores.

Carga refere-se ao número de processos aguardando para ser executado. Você aparentemente tem 10 processos que precisam ser executados na CPU. Quem sabe o que eles precisam fazer? Mas se você está apenas permitindo que os processos do MLTest sejam executados em algumas CPUs (lembre-se, 1 processo por CPU), então você (poderia) ter alta carga porque todos esses processos estão sempre em execução ou esperando para serem executados. Deixando mais processos, você pode fazer mais coisas mais rápido, então você não terá que esperar para correr a maior parte do tempo.

No entanto, este é apenas um cenário teórico. Para resolver especificamente o problema, você precisa responder:

1) o que (processo) está esperando para executar (causando carga)? 2) Você está restringindo o número de processos MLTest que podem ser executados? 3) Se você permitir que mais processos do MLTest sejam executados, ele "terminará" seu problema / programa mais rapidamente?

    

Answer 5

Várias coisas podem causar isso, e eu diria primeiro que isso não é motivo para alarme ou preocupação.

Não sabendo mais nada sobre o que você está fazendo do que a lista de processos que você incluiu expõe, e não sabendo nada realmente sobre o Matlab, eu vou sugerir algumas coisas possíveis que estão acontecendo que são completamente normais, e podem resultar no que você está vendo.

Primeiro, porém, quero salientar que top está mostrando um valor médio durante um certo período de tempo, e provavelmente um valor muito curto - na ordem de alguns segundos. Um de seus processos rodando a apenas 93% por alguns segundos (ao invés de 100%) não é uma coisa enorme. É provavelmente até 100% (e um processo diferente até 93%) no próximo intervalo.

Voltar para o porquê:

Se um processo fizer qualquer coisa que exija uma chamada de sistema, especialmente E / S de disco, pode ficar inativo por um tempo aguardando a conclusão dessa operação. Isso resultará em < 100% de uso da CPU, como parte do tempo que ele está bloqueando na E / S. Processos de outros usuários definitivamente têm um efeito aqui. Pode haver núcleos mais do que suficientes, mas se todos competirem por largura de banda no mesmo disco rígido, ninguém verá 100% de utilização da CPU.

Seu aplicativo parece usar vários processos ou até vários segmentos de uma só vez. Isso pode acelerar as coisas até certo ponto (e isso depende diretamente do aplicativo e de como ele está dividindo o trabalho). No entanto, isso também pode ter um custo associado a ele quando se trata de comunicação entre processos. Se, por exemplo, cada processo filho (ou thread) tiver que se comunicar entre si, o número de canais de comunicação aumentará significativamente à medida que o número de processos aumentar. Mesmo que cada processo esteja apenas se comunicando com um processo principal responsável, os filhos podem bloquear a comunicação com o pai, conforme o pai fala com um filho diferente. Isso não é tão diferente do bloqueio na E / S do disco.

No final, mesmo com um número infinito de núcleos, você provavelmente verá retornos decrescentes com cada processo adicional usado para fazer seu trabalho. Há provavelmente um ponto ideal em algum lugar, e talvez seja 6, como seu colega sugere. Mas eu não usaria sua análise (procurando por < 100% de utilização) para determinar onde está esse ponto ideal.