[FUG-BR] RES: [OT?] SWAP 2x RAM
Patrick Tracanelli
eksffa em freebsdbrasil.com.br
Sexta Novembro 28 11:29:19 BRST 2008
Renato Frederick escreveu:
> Mas considere que eu desativo o core dump, até porque tive um problema com
> um aplicativo simples(gocr) que dava crash cada vez que escaneava emails(era
> uma lib errada)... acabou por lotar o disco com centenas de dump.. :)
>
> Concordo com a janela de tempo que um swap oferece, mas ainda não obtive
> nada de concreto sobre valores.. já vi gente usar swap=RAM, swap=2xRAM...
> eu a partir de 4GB de RAM uso swap=RAM... mas fica só no "acho" mesmo, nada
> oficial
>
> Abraços
>
>> Não tenho a explicação oficial, mas eu já passei por algumas situações
>> onde o Free dá pau e é necessário gerar um crash dump da memória, isso
>> quer dizer que quando ocorre algum kernel panic, no proximo reboot o
>> swap é utilizado para "copiar" o conteúdo da memória antes de gerar o
>> crash dump, se você tiver o swap menor ou do tamanho exato da memória
>> você não consegue gerar o dump. Este tipo de crash dump é utilizado
>> para diagnóstico/correção do problema.
>>
>> Outras razão seria estabilidade mesmo, de repente você tem uma
>> aplicação que por algum motivo começa a consumir MUITA memória, você
>> tendo um swap grande vai ter mais tempo para atuar antes de começar a
>> tomar vários erros. Claro que em todo o caso esqueça performance
>> quando o swap é usado, mas isso já é outra historia....
>> -------------------------
>> Histórico: http://www.fug.com.br/historico/html/freebsd/
>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>
> -------------------------
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Não importa a quantidade de memória RAM, o ideal é 2xSWAP porque os
algorítimos de tomada de decisão do VM Subsystem conta com pelo menos
essa quantidade para definir o que fazer, sem desvios (e SWAP inferior a
2xRAM seria um desvio, SWAP inferior a 1xRAM é um segundo checkpoint
desviado e por último o pior, SWAP inferior a 256M é o terceiro desvio;
o quarto desvio é não ter SWAP e um quinto desvio não estudado é com
SWAP acima de 2xRAM).
Essa é uma racterística do 4.4BSD e muito mais acentuada no FreeBSD onde
o McKusick atuou com muita enfase nas melhorias do sistema de arquivos e
gerenciamento de memória. Gerenciamento de memória no FreeBSD sempre foi
mesmo uma questão que deixa quem ta acostumado com outros sistemas um
pouco confuso porque não fica usando decisões típicas como aplicando
LRU, MRU, pra decidir o que entra ou sai da swap. Alias não existe
diferença entre SWAP, RAM ou File System do ponto de vista do usuário
(apenas o kernel sabe o que é o que).
De qualquer forma se é preciso apenas uma referência "formal" segue o
trecho relevante de "man 7 tuning":
-----
You should typically size your swap space to approximately 2x main
memory. If you do not have a lot of RAM, though, you will generally
want a lot more swap. It is not recommended that you configure any less
than 256M of swap on a system and you should keep in mind future memory
expansion when sizing the swap partition. The kernel's VM paging
algorithms are tuned to perform best when there is at least 2x swap
versus main memory. Configuring too little swap can lead to
inefficiencies in the VM page scanning code as well as create issues
later on if you add more memory to your machine.
-----
Na prática no FreeBSD 3 era ainda ideal 2xRAM divididos em 4 partições
distintas de SWAP. No 4.x o Matt Dillon (orientado pelo McKusick) deixou
de fazer o Fixed Interleave e conseguiu manter a mesma performance com
Dynamic Interleave usando pra isso o algorítimo de estrutura de dados
Radix Tree (árvore Radix, um tipo especial de Trie - árvore ordenada -
típica coisa que meu professor de E.D. não ensinou na graduação, ele
preferia complicar em pascal uma fila/lista do que ensinar algorítimos
que o valham, em linguagem que o valha).
Uma visão um pouco técnica porém não muito de como o VM subsystem
funciona pode ser encontrada aqui:
http://www.freebsd.org/doc/en/articles/vm-design/
Um trecho introdutório que eu gosto muito:
"Much of the apparent complexity of the FreeBSD design, especially in
the VM/Swap subsystem, is a direct result of having to solve serious
performance issues that occur under various conditions. These issues are
not due to bad algorithmic design but instead rise from environmental
factors. In any direct comparison between platforms, these issues become
most apparent when system resources begin to get stressed. As I describe
FreeBSD's VM/Swap subsystem the reader should always keep two points in
mind. First, the most important aspect of performance design is what is
known as “Optimizing the Critical Path”. It is often the case that
performance optimizations add a little bloat to the code in order to
make the critical path perform better. Second, a solid, generalized
design outperforms a heavily-optimized design over the long run. While a
generalized design may end up being slower than an heavily-optimized
design when they are first implemented, the generalized design tends to
be easier to adapt to changing conditions and the heavily-optimized
design winds up having to be thrown away. Any codebase that will survive
and be maintainable for years must therefore be designed properly from
the beginning even if it costs some performance."
Historicamente o principal responsavel pelo gerenciamento de memoria no
Linux, o Rik Van Riel (que eu tive o prazer de conhecer, morou anos no
Brasil quando era funcionário da Conectiva; hoje é da Red Hat) sempre
defendeu que o gerenciamento de memória do Linux fosse como do FreeBSD.
Bateu de frente várias vezes com o Torvalds e acabou que as
complexidades que todos achavam não deixaram o RVR finalizar seu
trabalho como ele queria (em outras palavras o Torvalds tomou decisão
unilateral parecida com a que ele tomou recentemente quando incluiu o
CFS como escalonador padrão no Linux apesar de muita gente - boa -
apontar outras opções melhores e ja existentes pro Linux - inclusive a
própria Red Hat).
http://kerneltrap.org/node/46 vale pela curiosidade da epoca em que o
Riel queria muito tornar o VM Subsys do LX mais próximo que do FreeBSD e
seus motivos pelos quais FreeBSD tem melhor performance sob grande carga.
Desde então Riel costuma trabalhar com Memory Split no Red Hat
Enterprise pra amenizar (e melhorar dentro do possível sem trocar o VM
Subsys do Linux - sim o kernel do RHE tem grandes diferenças quando
comparado a outros LX - mais referencias em codigo:
http://www.surriel.com/patches/).
Agora explicações bem mais ténicas, a gente discutia (eu e outros)
quando eu dava aula de SO 1 na FUMEC. Infelizmente em 1 semestre só dava
pra dar enfase no gerenciamento de memória e escalonamento de processos.
Referência principal são os capítulos 5 e 6 do livro The Design and
Implementation of the FreeBSD Operating System.
Na prática as referencias desses 2 (especialmente o 5) capitulos se
aplicam aos vm_map.c vm_meter.c vm_mmap.c vm_kern.c vm_page.c
swap_pager.c em src/sys/vm; onde vemos a inicialização e a alocação
sempre associada ao dobro da RAM com páginas de memória sendo as
unidades de medida páginas de memória
dmmax = SWB_NPAGES * 2;
Então voltando mais pro "mundo do sysadmin" a SWAP ideal teria que ser:
(vm.stats.vm.v_page_count * 2) * hw.pagesize
Isso em bytes. As variáveis citadas são MIBs Sysctl então podemos
calcular em bytes o que o kernel espera ter de swap pra ser otimizado
(digite no seu sistema):
echo "((`sysctl -n vm.stats.vm.v_page_count`) * 2 ) * `sysctl -n
hw.pagesize`" | bc
Como SWAP é contabilizada em vm_page.c e swap_pager.c em unidades de 1K,
podemos calcular em K quantos "blocos" para SWAP é preciso ter pra estar
otimizado de acordo com o algorítimo:
echo "(((`sysctl -n vm.stats.vm.v_page_count`) * 2 ) * `sysctl -n
hw.pagesize`)/1024"
O comando "swapinfo" vai informar se estamos próximos disso (OK se
estiver acima, mal se estiver abaixo). A tentativa de criação de Zonas
de memória virtual abaixo do ideal acontece 2/3 em 2/3 (sim é bastante,
é drástico), a gente consegue observar isso no trecho seguinte do
arquivo swap_pager.c:
----------
/*
* if the allocation failed, try a zone two thirds the
* size of the previous attempt.
*/
n -= ((n + 2) / 3);
} while (n > 0);
if (n2 != n)
printf("Swap zone entries reduced from %d to %d.\n",
n2, n);
n2 = n;
/*
* Initialize our meta-data hash table. The swapper does not
need to
* be quite as efficient as the VM system, so we do not use an
----------
Depois disso as decisões são tomadas de acordo com os checkpoints que eu
citei no começo do e-mail. Porém esses checkpoints estao um pedacinho em
cada arquivo fonte citado hehe então não da pra colar simplesmente sem
contexto, tem mesmo que ser utilizado.
Mas enfim, pro sysadmin geral basta seguir recomendação de "man 7
tuning" e tudo fica bem no final. Os motivos estão ai, em livro e em código.
Desculpem a nerdisse. Esse é um assunto que eu gosto bastante e tentei
ser sucinto.
--
Patrick Tracanelli
FreeBSD Brasil LTDA.
Tel.: (31) 3516-0800
316601 em sip.freebsdbrasil.com.br
http://www.freebsdbrasil.com.br
"Long live Hanin Elias, Kim Deal!"
Mais detalhes sobre a lista de discussão freebsd