Por que trocar é usado quando resta muita memória livre?

35

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á muita memória livre disponível.

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

Nota:
meu processo MySQL está usando mais de 160% da energia da CPU por algum motivo; Não sei por que, mas não tenho mais de 70 usuários simultâneos ...

linux mysql php

— user1179459
fonte

Os aplicativos podem usar mais de 100% da CPU no Linux? Erm ...

— BlueRaja

5

@BlueRaja: Sim, porque no Linux a utilização da CPU é medida em relação a uma única CPU, nem todas as CPUs do seu sistema. Portanto, em uma máquina com 8 CPUs, você tem no máximo 800% de CPU disponível.

— precisa saber é o seguinte

Qual versão do MySQL você está usando ???

— RolandoMySQLDBA

@RolandoMySQLDBA versão 5.5

— user1179459

61

Isso é perfeitamente normal.

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

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

Mas o sistema sabe que talvez queira usar essa memória física para coisas como um cache de disco ou de outras maneiras que melhorem o desempenho. O mesmo acontece com a troca oportunista. Quando não tem nada melhor para fazer, grava dados que não são usados há muito tempo no disco, usando espaço de troca. No entanto, ainda mantém as páginas na memória física. Portanto, eles ainda podem ser acessados sem precisar trocá-los.

Agora, se o sistema mais tarde precisar dessa memória física para outra coisa, ele pode simplesmente jogar fora essas páginas porque já as escreveu para trocar. 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 no disco. Mas se o sistema precisar dessa memória para outro objetivo, não precisará escrevê-la primeiro. Grande vitória por toda parte.

— David Schwartz
fonte

Nesse caso, você pode explicar por que às vezes o espaço de troca não é de todo usado. Mem: total de 49554484k, 4087592k usado, 45466892k livre, 349244k buffers de swap: total de 94204k, 0k usado, 94204k livre, 1113644k em cache

— ananthan

4

@ananthan: Pode haver muitas razões. O mais provável é que o sistema nunca tenha sofrido nenhuma pressão de memória, mesmo devido a gravações em buffer, portanto o código de troca oportunista pode nunca ter sido acionado. Também poderia ser que alguém pensou que qualquer utilização de swap era ruim e assim mis-sintonizados o sistema não troca oportunista (reduzindo swappiness ).

— David Schwartz

6

Isso pode acontecer se em algum momento no passado você precisou de mais memória do que a 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 do swap não são lidos automaticamente novamente na RAM: isso só acontece quando os dados no swap são realmente necessários por algum processo. Isso é perfeitamente normal.

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

— brain99
fonte

O uso sem troca não é uma marca d'água alta. Quando as páginas trocadas são mapeadas de volta, as páginas do disco são marcadas como não em uso (mas ainda podem conter dados).

— symcbean

Eu só mencionou um cenário em que você pode ter uso de troca, mas isso na verdade nem sempre é sintomático de ter memória física não é suficiente - como também explicado por David Schwartz acima

— brain99

3

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

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

— Daemon of Chaos
fonte

1

Isso aumentará a tendência de recuperação de cache / buffers. Infelizmente, não está claro, desde a pergunta original, se o número de 29,53% inclui buffers / cache - se não, então, fazer a alteração que você sugerir terá um impacto adverso no desempenho. Se este dbms está usando InnoDB extensivamente em seguida, ele provavelmente foi mal configurado (embora uma caixa de 16gb 8 de núcleo único para ser utilizado como um servidor web é uma escolha BAD deisgn para começar)

— symcbean

por que você diz que é uma má escolha para o servidor web? Eu não usar o InnoDB quanto eu ainda prefiro myisam porque meu leituras são 70% e escreve apenas 30% ....

— user1179459

1

Provavelmente, como David explicou, é um comportamento normal do Kernel do Linux, mas também pode ser uma ocorrência do problema de “troca de insanidade” do MySQL . No seu caso (8 CPU, 16 GB RAM 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 do MySQL InnoDB de 4 GB.

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

Quando o sistema é iniciado, os processos são espalhados em todos os nós NUMA, usando parte de sua memória.
Quando o MySQL é iniciado, ele aloca 4 GB para o buffer pool InnoDB, preenchendo a RAM de um nó NUMA e usando alguma RAM em outros nós.
Então, o kernel do Linux, que não pode mover a RAM alocada de um nó NUMA para outro, considera uma boa ideia trocar as páginas do nó faminto (ou precisa trocar as páginas porque as páginas precisam 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).

— jfg956
fonte