sistema de blocos de troca GNU / Linux

Question

Eu usei o GNU / Linux em sistemas de 4 MB de RAM a 512 GB de RAM. Quando eles começam a trocar, na maioria das vezes você ainda pode entrar e matar fora do processo ofensivo - você só tem que ser 100-1000 vezes mais paciente.

No meu novo sistema de 32 GB que mudou: bloqueia quando é iniciado troca. Às vezes com atividade de disco cheio, mas outras vezes sem atividade do disco.

Para examinar qual poderia ser o problema, escrevi este programa. o ideia é:

1 grab 3% of the memory free right now
2 if that caused swap to increase: stop
3 keep the chunk used for 30 seconds by forking off
4 goto 1

-

#!/usr/bin/perl

sub freekb {
    my $free = 'free|grep buffers/cache';
    my @a=split / +/,$free;
    return $a[3];
}

sub swapkb {
    my $swap = 'free|grep Swap:';
    my @a=split / +/,$swap;
    return $a[2];
}


my $swap = swapkb();
my $lastswap = $swap;
my $free;
while($lastswap >= $swap) {
    print "$swap $free";
    $lastswap = $swap;
    $swap = swapkb();
    $free = freekb();
    my $used_mem = "x"x(1024 * $free * 0.03);
    if(not fork()) {
    sleep 30;
    exit();
    }
}
print "Swap increased $swap $lastswap\n";

Executar o programa para sempre deve manter o sistema no limite de trocando, mas apenas pegando uma quantia mínima de swap e fazendo isso lentamente (ou seja, alguns MB de cada vez, no máximo).

Se eu correr:

forever free | stdbuf -o0 timestamp > freelog

Eu deveria ver a troca aumentando lentamente a cada segundo. (para sempre e timestamp de link ).

Mas esse não é o comportamento que vejo: vejo o swap aumentando em saltos e que o sistema está completamente bloqueado durante esses saltos. Aqui o sistema é bloqueado por 30 segundos com o uso de swap aumenta com 1 GB:

secs
169.527 Swap:     18440184     154184   18286000
170.531 Swap:     18440184     154184   18286000
200.630 Swap:     18440184    1134240   17305944
210.259 Swap:     18440184    1076228   17363956

Bloqueado: 21 segundos Aumento de troca de 2400 MB:

307.773 Swap:     18440184     581324   17858860
308.799 Swap:     18440184     597676   17842508
330.103 Swap:     18440184    2503020   15937164
331.106 Swap:     18440184    2502936   15937248

Bloqueado: 20 seg. Aumentar Swap 2200 MB:

751.283 Swap:     18440184     885288   17554896
752.286 Swap:     18440184     911676   17528508
772.331 Swap:     18440184    3193532   15246652
773.333 Swap:     18440184    1404540   17035644

Bloqueado: 37 seg. Aumento de troca de 2400 MB:

904.068 Swap:     18440184     613108   17827076
905.072 Swap:     18440184     610368   17829816
942.424 Swap:     18440184    3014668   15425516
942.610 Swap:     18440184    2073580   16366604

Isso já é ruim o suficiente, mas o pior é que o sistema às vezes pára de responder - mesmo se eu esperar por horas. Eu tenho o sentindo que isso está relacionado ao problema de troca, mas não posso dizer com certeza.

Minha primeira idéia foi ajustar / proc / sys / vm / swappiness de 60 para 0 ou 100, só para ver se isso teve algum efeito. 0 não tinha um efeito, mas 100 causaram o problema com menos frequência.

Como posso evitar que o sistema bloqueie por tanto tempo?

Por que decide trocar 1-3 GB quando menos de 10 MB seria suficiente?

Informações do sistema:

$ uname -a
Linux aspire 3.8.0-32-generic #47-Ubuntu SMP Tue Oct 1 22:35:23 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Editar:

Eu testei se o problema é devido a 32 GB de RAM, removendo 24 GB e tentando com apenas 8 GB - vejo o mesmo comportamento.

Eu também posso reproduzir o comportamento de troca (embora não o congelamento) instalando o GNU / Linux Mint 15 no VirtualBox.

Não consigo reproduzir o problema no meu laptop de 8 GB: o script acima é executado lindamente por horas e horas - trocando alguns megabytes, mas nunca um gigabyte completo. Então eu comparei todas as variáveis em / proc / sys / vm / * em ambos os sistemas: Eles são exatamente os mesmos. Isso me leva a acreditar que o problema está em outro lugar. O laptop roda um kernel diferente:

Linux hk 3.2.0-55-generic #85-Ubuntu SMP Wed Oct 2 12:29:27 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Talvez algo no sistema VM tenha mudado de 3.2.0 para 3.8.0

    

Answer 1

O problema desapareceu após a atualização para:

Linux aspire 3.16.0-31-lowlatency #43~14.04.1-Ubuntu SMP PREEMPT Tue Mar 10 20:41:36 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Não é dado que foi esta atualização do kernel, que corrigiu isso.

    

Answer 2

Verifique qual agendador de E / S você está usando no dispositivo de bloco de troca, tente alterá-lo para obter melhores resultados.

link