O que a métrica Process / CPU inop significa realmente?

3

Estou usando o excelente no topo para analisar detalhadamente o impacto do teste de carga e a distinção entre a métrica SystemLevel / CPU no topo ( de todo o sistema) e a métrica ProcessLevel / CPU na seção inferior (por processo) me desconcertou. Estou ciente de questões semelhantes, mas não encontrei nenhuma que explique o uso do contexto que já entendi.

1. É% da capacidade disponível ou% da capacidade usada?

A métrica ProcessLevel / CPU é descrita na página de manual como "A porcentagem de ocupação desse processo relacionada à capacidade disponível para este recurso no nível do sistema. " Compare isso com:

  • ProcessLevel / DSK ("A porcentagem de ocupação desse processo relacionada à carga total que é produzida por todos os processos (ou seja, acesso total ao disco por todos os processos durante o último intervalo).") e com

  • O equivalente aparente "CPU Usage" do top ("A parte da tarefa do tempo de CPU decorrido desde a última atualização de tela, expressa como uma porcentagem do tempo total da CPU.")

Ambos parecem se referir à porcentagem de ocupação relacionada à "... capacidade usada ...", o que é bem diferente de "... disponível capacidade ... ". Assumindo que a descrição do manual está correta ...

2. O que é "capacidade disponível"?

Se estiver realmente monitorando a "capacidade disponível", o que isso significa? A ilustração abaixo, com ProcessLevel / CPU a 97% quando a CPU está 43% ociosa, parece mostrar que ela não pode estar relacionada com o SystemLevel / CPU maxima. Poderia levar em conta o tempo de espera do disco ou da rede?

3. Como pode ser > 100%?

Isso é apenas erro estatístico / de amostragem? Está sujeito ao mesmo "100% = 1 CPU maximizado" que a% CPU do topo? Em caso afirmativo, como pode o nosso nó pal de single-thread usar > 100% na amostra final abaixo?

Amostras ilustrativas

A título de ilustração (pode abrir wormcans node / xen / aws adicionais, e nesse caso desculpe, mas eu ainda apreciaria a sabedoria do SF e ficaria feliz em gerar outras perguntas) ...

O aplicativo do nó que estou testando (com o também excelente vegeta ) manipula um tipo de solicitação de uploady feliz em um 4 -CPU AWS instance a uma taxa de 10req / s. Sob essa carga, o ProcessLevel / CPU do nó está em torno de 69%:

CPU sys: 73% | user: 155% | irq: 6% | idle: 143% | wait:    21% | steal: 1%
cpu sys: 18% | user:  36% | irq: 0% | idle:  43% | cpu002 w: 3% | steal: 0%

...                 blah                 ...           CPUNR    CPU    CMD
                                                           2    69%    node

(estou assumindo que o cpu002 corresponde ao CPUNR = 2).

Sob uma carga de 14 req / s, que o servidor não controla (35% de tempo limite), o ProcessLevel / CPU para o nó está em 97%:

CPU sys: 59% | user: 142% | irq: 5% | idle: 170% | wait:    22% | steal: 1%
cpu sys: 14% | user:  40% | irq: 0% | idle:  42% | cpu003 w: 3% | steal: 0%

...                 blah                 ...           CPUNR    CPU    CMD
                                                           3    97%    node

Portanto, se ProcessLevel / CPU significa% de recursos de CPU available , como o nó pode estar usando 97% do recurso de CPU disponível quando sua CPU está 43% ociosa? Ou (correndo o risco de se desviar levemente do tópico), se ProcessLevel / CPU significa% de usado recurso da CPU, por que essa métrica corresponderia tão intimamente a uma carga máxima, quando há bastante CPU disponível e não está esperando pelo disco (maximizando o adaptador de rede ...)?

Amostra final, para a pergunta > 100%, aqui está a mesma caixa ficando realmente martelada em 16 req / s (ProcessLevel / CPU agora até 111% e todas as solicitações estão falhando):

CPU sys: 44% | user: 125% | irq: 4% | idle: 203% | wait:    24% | steal: 1%
cpu sys: 12% | user:  38% | irq: 4% | idle:  41% | cpu001 w: 5% | steal: 0%

...                 blah                 ...           CPUNR    CPU    CMD
                                                           1   111%    node

Felicidades!

    
por Dave Gregory 22.09.2015 / 13:21

0 respostas