Ubuntu Server 12.04 CPU Load

Question

Eu tenho um servidor (2x Hexa-Core Xeon E5649 2,53 GHz com HT de 32 GB de RAM e 20000 GB de largura de banda) executando o Ubuntu Server 12.04 LTS. O servidor executa o LAMP e serve apenas um site, o número estimado de usuários deve ser de ~ 15.000 ao mesmo tempo.

No momento eu tenho cerca de 2000 usuários on-line, cada um deles executa 50 consultas MySQL (pequenos valores selecionados e inseridos) desde o início até o final da sessão. A carga da CPU do servidor é alta neste número de conexões, enquanto o uso da RAM é de quase 1GB de 32GB, vale a pena mencionar que o servidor estava rodando muito rápido sem problemas, mas está preocupado com a média de carga. link

top - 03:02:43 up 9 min,  2 users,  load average: 50.83, 30.14, 12.83
Tasks: 432 total,   1 running, 430 sleeping,   0 stopped,   1 zombie
Cpu(s):  0.1%us,  0.2%sy,  0.0%ni, 66.5%id, 33.1%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  32939992k total,  3111604k used, 29828388k free,    84108k buffers
Swap:  2048280k total,        0k used,  2048280k free,  1621640k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                          
 2860 root      20   0 25820 2288 1420 S    3  0.0   0:11.18 htop                                                                                             
 1182 root      20   0     0    0    0 D    2  0.0   0:01.46 kjournald                                                                                        
 1935 mysql     20   0 12.3g 161m 7924 S    1  0.5 102:31.45 mysqld                                                                                           
   11 root      20   0     0    0    0 S    0  0.0   0:00.38 kworker/0:1                                                                                      
 1822 www-data  20   0  247m  25m 4188 D    0  0.1   0:01.81 apache2                                                                                          
 2920 www-data  20   0     0    0    0 Z    0  0.0   0:01.20 apache2 <defunct>                                                                                
 2942 www-data  20   0  247m  23m 3056 D    0  0.1   0:00.20 apache2                                                                                          
 3516 www-data  20   0  247m  23m 3028 D    0  0.1   0:00.06 apache2                                                                                          
 3521 www-data  20   0  247m  23m 3020 D    0  0.1   0:00.09 apache2                                                                                          
 3664 www-data  20   0  247m  23m 3132 D    0  0.1   0:00.09 apache2                                                                                          
 3674 www-data  20   0  247m  23m 3252 D    0  0.1   0:00.06 apache2                                                                                          
 3713 www-data  20   0  247m  23m 3040 D    0  0.1   0:00.09 apache2                                                                                          
    1 root      20   0 24328 2284 1344 S    0  0.0   0:03.09 init                                                                                             
    2 root      20   0     0    0    0 S    0  0.0   0:00.00 kthreadd                                                                                         
    3 root      20   0     0    0    0 S    0  0.0   0:00.01 ksoftirqd/0                                                                                      
    6 root      RT   0     0    0    0 S    0  0.0   0:00.00 migration/0                                                                                      
    7 root      RT   0     0    0    0 S    0  0.0   0:00.00 watchdog/0                                                                                       
    8 root      RT   0     0    0    0 S    0  0.0   0:00.00 migration/1                                                                                      
    9 root      20   0     0    0    0 S    0  0.0   0:00.00 kworker/1:0


root@server:~/codes# vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
19  0      0 29684012  86112 1689844    0    0    19   590  254  231 48  0 47  5
23  0      0 29704812  86128 1697672    0    0     4   320 11100 8121 77  1 22  0
33  0      0 29671044  86156 1705308    0    0     0  5440 13190 9140 95  1  4  0
33  3      0 29670088  86160 1706288    0    0     0 32932 12275 7297 99  0  1  0
35  0      0 29693456  86188 1710724    0    0     4   676 12701 7867 98  1  1  0
^C

Eu não mudei nenhuma das configurações padrão que vem com o Ubuntu. Esta carga é normal para um servidor tão poderoso? existe alguma otimização que eu possa fazer para o Apache / MySQL para minimizar a carga? O que você recomendaria?

EDIT: LOAD AVERAGE at 52 !!!!!!! link

**** ATUALIZAÇÃO **** Acontece que o DBA não adicionou índices às tabelas, depois de adicionar índices a média de carga caiu drasticamente de 93 para 1.2 :) Tudo é super incrível, obrigado a todos pela ajuda!

    

Answer 1

Parece bem para mim.

Você tem 12 núcleos ... em CPUs de 2x 6 núcleos. Portanto, com 100% de desempenho, sua média de carga deve ser 12.

A média de carga é engraçada . Eu não acho que isso significa o que você acha que significa.

A média de carga é, na verdade, uma indicação de quantos processos estão sendo executados a qualquer momento, com uma média de mais de 1, 5 e 15 minutos de janelas.

Parece-me que você está um pouco comprometido demais, mas não drasticamente.

Talvez use o link para ter uma idéia de como as configurações do mysqld equivalem aos valores reais de uso.

O próximo passo lógico é separar o MySQL e o Apache em caixas diferentes. Eu não tenho certeza se você está nesse nível ainda, porque você ainda tem um pantload de RAM livre para o MySQL engolir isso. Você pode encontrar algum benefício de tornar caches de consulta e buffers de chaves maiores, e provavelmente ter uma visão mais profunda do log de consultas lentas do MySQL , e ver se você pode otimizar as tabelas de todo.

Há muitas informações sobre como ler as médias de carga e, na verdade, é mais sensato dividir o número médio da carga pelo número de núcleos, então você tem uma ideia de como o servidor realmente funciona.

Eu posso ver agora que você tem 33% de iowait. Eu suspeito .. que você tenha um banco de dados razoavelmente pesado, e isso está causando o bloqueio de tabelas quando você está escrevendo, o que significa que gravações simultâneas não podem acontecer.

Tendo cheirado no meu.cnf, parece que o max_connections é bastante alto, mas isso não é uma grande preocupação , mas significa que, se você estiver usando todos eles, precisará de 27 GB de RAM para permitir isso. Que é muito, mas não uma preocupação enorme, novamente.

Considere girando no PHP APC Opcode caching .

** Editar **

Tendo visto o log de consultas agora, estou inclinado a pensar que há algumas coisas que podem beneficiar o servidor.

1. PHP APC Opcode caching (torna o apache mais eficiente em geral)
2. Converta todas as tabelas para o InnoDB, a menos que você tenha um bom motivo realmente . Se esse motivo for a pesquisa de texto completo, encontre uma maneira melhor de fazê-lo e mude para o InnoDB.
3. Compre outro servidor e torne-o um host DB dedicado. Ajuste-o com discos SAS e separe-o em partições para que o registro e os dados fiquem em eixos separados (ou melhor, matrizes RAID).

Sem um olhar muito mais profundo sobre o que está acontecendo, é difícil dizer realmente.

Pode valer um teste com NewRelic para PHP. É grátis por um mês e tende a dar uma boa visão sobre os maus cheiros do código.

Como alternativa, estou disponível para consultoria;)

    

Answer 2

Há um ponto marcante na sua saída principal e esse é o número de processos no estado D. Uma boa parte do apache2 e até do kjournald é mesmo no estado D. Processos de estado D são conhecidos por aumentar a carga da CPU.

Geralmente, um processo entra no estado D quando espera pelo IO. Depois de obter o IO, ele chega novamente ao estado R ou S do D. A próxima coisa que você pode fazer para executar a depuração ao vivo é verificar quanto tempo esses processos do estado D estão sendo executados. Se por algum tempo, um problema.

De qualquer forma, o seu problema, se for alta carga média encontra-se em IOwait como 33,1% é o valor do iowait relatado pelo topo. % usr e% sys não são muito, então podemos ignorar com segurança que os processos estão ficando descontrolados ou a CPU está em execução ou há um gargalo com a memória. O problema é iowait, aparentemente. Eu trabalho principalmente com o RHEL, por isso não tenho 100% de certeza sobre o Ubuntu e se existem ferramentas embutidas.

O que eu mais faço é coletar, várias iterações de top, vmstat por algum tempo, iostat por algum tempo (com os interruptores apropriados que mostram a quebra do dispositivo), uma iteração de ps e ps -xv e verificá-los. Muitas vezes, o primeiro nível de depuração pode ser feito a partir disso. Em seguida, posso coletar algumas saídas oprofile, perf dependendo da versão do RHEL, mas isso é outra história.

Independentemente disso, verifique todos os comandos de depuração ao mesmo tempo para obter uma visualização mais detalhada.

    

Answer 3

Eu suspeito que o processo talvez esteja aguardando o IO, o que pode fazer com que a média de carga seja alta. Depois de toda a carga média depende da fila de processos executáveis para cpu. Você vê algum valor alto no comando iostat?

    

Answer 4

Eu já tive esse tipo de situação antes, quando basicamente com carga mínima de servidor, o site parece estar respondendo muito devagar.

O Top não utilizou nenhum processo que esteja consumindo muito de memória RAM ou cpu. Mas o mais alarmante foi o Server Laod e o tempo de espera do cpu. Como no seu caso, é 33%.

No meu caso, o problema acabou sendo no Server Hosting Company. Sua SAN vem se apresentando muito lenta por semanas antes de finalmente decidir mudar seu armazenamento. Somente depois que meu servidor começou a funcionar bem.

O meu era um VPS e não um servidor dedicado.

    

Answer 5

Eu tive um problema semelhante com a versão para desktop do Ubuntu 12.04 (ele estava sendo usado como um servidor (não minha escolha)).

Se você instalou um gerenciador de área de trabalho em sua caixa, pode achar que o vsync é o problema.

O Unity dm estava me causando uma carga de CPU permanentemente elevada para eu desligar o vsync instantaneamente. Não sei se outros dm estão causando esse problema também.