Por que a troca é usada quando a memória livre é suficiente?

34

Eu tenho um bom servidor web (dedicado) com bons recursos de memória:

System information
Server load     2.19 (8 CPUs)   
Memory Used     29.53% (4,804,144 of 16,267,652)    
Swap Used   10.52% (220,612 of 2,097,136)   

Como você pode ver, meu servidor está usando swap quando há muita memória livre disponível.

Isso é normal ou há algo errado com a configuração ou a codificação?

N.B.
Meu processo do MySQL está usando mais de 160% da energia da CPU por algum motivo; Não sei porque, mas não tenho mais de 70 usuários simultâneos ...

    
por user1179459 24.08.2012 / 14:55

4 respostas

61

Isso é perfeitamente normal.

Na inicialização do sistema, vários serviços são iniciados. Esses serviços se inicializam, lêem arquivos de configuração, criam estruturas de dados e assim por diante. Eles usam alguma memória. Muitos desses serviços nunca serão executados novamente durante todo o tempo em que o sistema estiver ativo, porque você não os está usando. Alguns deles podem funcionar em horas, dias ou semanas. No entanto, todos esses dados estão na memória física.

Claro, o sistema não pode jogar esses dados fora. Não pode provar que literalmente nunca será acessado. Um desses serviços, por exemplo, pode ser o que fornece acesso remoto à caixa. Você pode não ter usado em uma semana, mas se você usá-lo, é melhor trabalhar.

Mas o sistema sabe que pode gostar de usar essa memória física para coisas como um cache de disco ou de outras maneiras que melhorarão o desempenho. Por isso, faz troca oportunista. Quando não tem nada melhor para fazer, ele grava dados que não são usados há muito tempo no disco, usando o espaço de troca. No entanto, ainda mantém as páginas na memória física. Então eles ainda podem ser acessados sem ter que trocá-los.

Agora, se o sistema mais tarde precisar dessa memória física para outra coisa, pode simplesmente jogar essas páginas fora, porque já as gravou para trocar. Isso dá ao sistema o melhor dos dois mundos. Os dados ainda são mantidos na memória, portanto, podem ser acessados sem precisar lê-los do disco. Mas, se o sistema precisar dessa memória para outra finalidade, não precisará escrevê-la primeiro. Grande vitória ao redor.

    
por 24.08.2012 / 15:10
6

Isso pode acontecer se, em algum momento no passado, você precisasse de mais memória do que de RAM física na máquina. Nesse momento, alguns dados serão gravados no espaço de troca.

Quando a memória posterior é liberada, os dados da troca não são lidos automaticamente de volta na RAM: isso só acontece quando os dados na troca são realmente necessários por algum processo. Isso é perfeitamente normal.

Quanto ao seu processo mysql: tudo depende do tipo de consultas que você executa. Em teoria, duas consultas muito complexas provavelmente seriam suficientes para obter essa carga, independentemente do seu número de usuários. Você pode ativar o log de consultas lentas para obter mais informações sobre quais consultas exigem muita carga.

    
por 24.08.2012 / 15:02
3

Você também pode alterar esse comportamento em sysctl -w vm.swappiness=10 , o que reduzirá bastante o uso do swap até que seja realmente necessário.

Quanto ao MySQL, você já realizou pelo menos um teste de configuração de linha de base usando o tuning-primer.sh script?

    
por 24.08.2012 / 16:21
1

Isso provavelmente é, como David explicou, um comportamento normal do Kernel Linux, mas também pode ser uma ocorrência do Problema de" insanidade de swap "do MySQL . No seu caso (8 CPU, 16 GB de RAM total, 5 GB usados), para que isso aconteça, seu computador deve ser um sistema NUMA com 4 nós (sockets) e 4 GB de RAM por nó e um buffer pool do MySQL InnoDB de 4 GB.

Em suma (você deve ler o link acima para detalhes completos), é isso que acontece:

  1. Quando o sistema inicia, os processos são distribuídos em todos os nós NUMA usando parte de sua memória.
  2. Quando o MySQL inicia, ele aloca 4 GB para o buffer pool do InnoDB, preenchendo a RAM de um nó NUMA e usando alguma RAM em outros nós.
  3. Em seguida, o kernel do Linux, que não pode mover a RAM alocada de um nó NUMA para outro, acha que é uma boa ideia trocar páginas do nó morto (ou precisar trocar páginas porque as páginas precisavam ser trocadas).

Para evitar isso, altere a alocação de memória para o MySQL alocar RAM em todos os núcleos (veja o link acima para mais detalhes).

    
por 23.05.2013 / 14:08