Qual é o valor apropriado de vm.swappiness ao usar o zram?

13

Estou usando o zram no meu computador como uma troca compactada suportada por RAM. Quando o sistema precisa trocar algo, trocá-lo para um arquivo de troca suportado por zram é mais ou menos equivalente a compactar esses dados na memória para liberar espaço. Isso torna a troca muito rápida na maioria das vezes, em relação à troca com suporte em disco. Por causa disso, pergunto-me se há algum desempenho a ser ganho, incentivando o sistema a trocar itens não utilizados de forma mais agressiva, pois isso pode ser feito sem atingir o disco?

Alguém já mexeu com, digamos, a configuração vm.swappinessde 100 enquanto usava o zram? Isso seria desejável?

sysctl -w vm.swappiness=100
Ryan C. Thompson
fonte
2
Esta é uma excelente pergunta e eu acho que alguns benchmarking é a fim de remover as opiniões e obter os fatos ...
Elder Geek
Boa ideia, e zram poderia ter melhorado desde 2012, quando eu o usei última :-)
Huygens
Fiz um pequeno teste e, até onde eu sei, a memória "reservada" para o zram ainda é usada como cache. Se isso for confirmado, acho que pode fazer sentido manter o swappiness baixo para evitar ciclos de CPU?
Vitor

Respostas:

2

Eu realmente não recomendaria colocar o swappiness mais alto. Um mecanismo comum no kernel é que ele coloca páginas (partes da memória) no swap para liberar memória para outras tarefas em execução.

Primeiro "problema" quando o kernel deseja que n páginas sejam liberadas, m (com m <n, m é o número de páginas compactadas necessárias para conter n) são criadas recentemente na RAM, não tenho certeza se isso pode perturbar o kernel ou não.

De qualquer maneira, quando você tiver páginas na troca, é possível que você use o aplicativo posteriormente com algumas de suas páginas na troca. O que o kernel faz é trazer de volta essas páginas para a memória física, mas não as remove da troca (que com troca padrão pode ser vista como cache , portanto, quando o aplicativo volta em segundo plano, o kernel não precisa gravar essas páginas para a troca lenta). No entanto, com o zram, talvez não seja um truque sábio, porque você terá na memória as m páginas em zram + as n páginas que estão de volta na memória!

O kernel normalmente possui uma "memória total" que pode ser usada para fazer seus negócios. Quando você adiciona o zram, ele conta apenas na memória "swap", como seria com qualquer troca baseada em disco, mas reduziu a "memória total" real e isso não é esperado / antecipado pelo kernel. Às vezes, você pode ter um comportamento estranho e não desejado por causa disso!

Com o zram, seria bom que o kernel não troque muito nessa área quando estiver sob pressão de memória. E você sempre deve ter uma partição de troca de disco rígido real maior que o tamanho máximo do seu zram, para que o sistema não obtenha OOM, enquanto ao mesmo tempo você veria bastante espaço livre, conforme relatado por free!

Huygens
fonte
O zram fornece dispositivos de bloco de RAM. Tudo o que é gravado nesses dispositivos de bloco é compactado. Se os dispositivos de bloco zram forem usados ​​como troca, quando o sistema tentar mover partes da memória para troca, ele moverá efetivamente a memória de uma parte da RAM para outra, exceto que os dados serão compactados antes de serem copiados para o destino. Isso funciona efetivamente como um mecanismo de compactação de memória barato para melhorar a capacidade de resposta em sistemas com quantidades limitadas de memória. ... O Zram está no teste desde o Linux 2.6.33. Na versão 3.14, o zram foi movido da preparação para drivers / block / zram.
Elder Geek
1
@ElderGeek exatamente! E vou dar um exemplo para ilustrar por que isso não é perfeito. O kernel tentará remover 64 MB de RAM, colocando-os na troca do zram. O pedaço de 64 MB compactado agora é 32 MB. O resultado é que a memória diminuiu 32MB e não 64MB. Agora, o que acontece quando o aplicativo requer os 64 MB de volta na memória, o kernel copia (e não move) o pedaço de volta na memória. Você tem agora 64 MB de RAM + 32 MB de zram. Por que copiar? Porque o kernel armazena em cache as páginas, como expliquei na minha resposta. Ambos os comportamentos não são ideais. E quando a memória não está bem compactável, isso é ainda pior.
Huygens
Ainda na fase de testes. Eu acho que deve haver alguma maneira de ajustar o algoritmo de cache usado pelo zram para liberar a página compactada quando ela é copiada de volta para a RAM não compactada.
Elder Geek
Eu tentei várias vezes até 2012. Naquele momento, meu computador estava limitado a 1 GB de RAM e, enquanto navegava na Internet, era dolorosamente lento (geralmente tenho de 10 a 50 guias abertas). Mas desde então nunca mais o usei. Tenho RAM mais do que suficiente para não usar mais o swap. Ao usar o zram com o Firefox naquela época, rapidamente comecei a "trocar", dada a pouca RAM que eu tinha. E rapidamente eu tive um sistema que não responde com muitas falhas. Sem zram, era dolorosamente lento, mas estável, pelo menos. Meu problema era que provavelmente estava constantemente compactando / descompactando páginas de memória.
Huygens
Sim, meus resultados foram um pouco parecidos. Em um sistema com 8 GB, consegui forçar um OOM iniciando várias VMs durante um trabalho de codificação. Você tem alguma experiência com o zswap? Parece uma alternativa viável com base no que li.
Elder Geek
2

Resposta curta: vm.swappiness=100é o valor apropriado para zram (pelo menos no Debian Stretch com Linux 4.9, acredito que seja o melhor valor)

Eu já testei vm.swappiness=100para mim.

Eu acho que você pode fazer um teste simples para garantir que valor é melhor para você.

Também fiz outro programa simples para testar esta questão. x Na minha máquina, um vm.swappinessvalor muito baixo (como vm.swappiness=1) causará um problema óbvio de resposta.

Sobre SwapCachedem /proc/meminfo:

Primeiro, tente vm.page-cluster=0, isso talvez possa reduzir alguns inúteis SwapCachedda troca.

O SwapCached pode acelerar o zram da mesma forma que o dispositivo de troca não-zram

SwapCached pode reutilizar (gratuito) quando necessário:

./linux-4.9/mm$ grep -rn delete_from_swap_cache
memory-failure.c:715:   delete_from_swap_cache(p);
shmem.c:1115:       delete_from_swap_cache(*pagep);
shmem.c:1645:            * unaccounting, now delete_from_swap_cache() will do
shmem.c:1652:               delete_from_swap_cache(page);
shmem.c:1668:       delete_from_swap_cache(page);
vmscan.c:673:       __delete_from_swap_cache(page);
swap_state.c:137:void __delete_from_swap_cache(struct page *page)
swap_state.c:218:void delete_from_swap_cache(struct page *page)
swap_state.c:227:   __delete_from_swap_cache(page);
swapfile.c:947:         delete_from_swap_cache(page);
swapfile.c:987: delete_from_swap_cache(page);
swapfile.c:1023:            delete_from_swap_cache(page);
swapfile.c:1571:            delete_from_swap_cache(page);
./linux-4.9/mm$ 
analfabeto
fonte
0

As páginas precisam ser trocadas (para o disco) quando a memória estiver cheia. Se você estiver usando a memória para criar um local para trocar as páginas quando a memória estiver cheia, seria de supor que isso supera o objetivo, exceto se a compactação fizer alguma diferença (e seria natural compactar a memória diretamente em vez de passar por ela troca). Acho que seria necessário avaliar isso, pois os computadores são cada vez mais rápidos na compactação e descompactação em comparação com a velocidade da memória.

Alexander
fonte
Eu descobri que o swap zram-suportado é bastante útil quando o sistema está ficando sem memória. Isso me salvou algumas vezes de ficar completamente preso no inferno e ter que reiniciar (estou analisando grandes conjuntos de dados, por isso preciso da memória, com todos os 24 GB). Só estou me perguntando se o vm.swappinessvalor está ajustado para a troca com suporte em disco e se devo alterá-lo, se eu usarei principalmente a troca com zram.
Ryan C. Thompson
1
"cada vez mais rápido"? Na compressão mosca foi um desempenho melhor do que direto ao disco I / O para mais do que a última década (sua nunca vai ser mais rápido do que o acesso à memória - que não é o ponto)
symcbean
symcbean, você esqueceu "comparado à velocidade da memória". Onde está o desacordo?
Alexander
Acho que o ponto do symcbean é que o objetivo das páginas com suporte a memória compactada (zram) é substituir a troca por meio físico. A razão pela qual não é "natural compactar a memória diretamente" é porque seria complicado para os aplicativos determinar quais partes da memória poderiam ser compactadas e quando; o subsistema VM é um local muito mais fácil de implementar isso. As cargas de trabalho que se beneficiam do zram têm páginas que não estão no conjunto de trabalho e podem ser facilmente compactadas.
Daniel Papasian