☰

Por que o Swap é usado quando resta bastante memória livre?

tag-icon • tag-icon linux mysql php
Por que o Swap é usado quando resta bastante memória livre?

Eu tenho um servidor web (dedicado) muito bom 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á bastante memória livre disponível.

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

NB
Meu processo 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...

Responder1

Isso é perfeitamente normal.

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

É claro que o sistema não pode descartar esses dados. Não pode provar que literalmente nunca será acessado. Um desses serviços, por exemplo, pode ser aquele que fornece acesso remoto à caixa. Você pode não usá-lo há uma semana, mas se usar, é melhor que funcione.

Mas o sistema sabe que pode querer usar essa memória física para coisas como cache de disco ou de outras maneiras que melhorem o desempenho. Portanto, faz trocas oportunistas. Quando não há nada melhor para fazer, ele grava no disco dados que não são usados ​​há muito tempo, usando espaço de troca. No entanto, ainda mantém as páginas na memória física. Assim, eles ainda podem ser acessados ​​sem a necessidade de trocá-los.

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

Responder2

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

Quando a memória posterior é liberada, os dados do swap não são lidos automaticamente na RAM: isso só acontece quando os dados do swap são realmente necessários para 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 tal carga, independentemente do número de usuários. Você pode ativar o log de consultas lentas para obter mais informações sobre quais consultas exigem muita carga.

Responder3

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

Quanto ao MySQL, você realizou pelo menos um teste de configuração de linha de base usando oajuste-primer.shroteiro?

Responder4

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

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

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

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

informação relacionada