[FUG-BR] RES: RES: [OT?] SWAP 2x RAM
Renato Frederick
frederick em dahype.org
Sexta Novembro 28 11:42:41 BRST 2008
Opa..
Obrigado Patrick, agora posso ter um embasamento para justificar o correto
dimensionamento do SWAP, que obviamente envolve custo.
Sobre outro colega que falou do tamanho do disco, realmente até uma certa
quantia de RAM e com poucos discos podemos considerar desprezível alocar
32GB para swap, mas quando está planejando a compra de um novo hardware,
esta informação deve ser levada em conta para os pré requisitos enviados ao
comercial.
No meu caso em particular, o correto dimensionamento do swap irá alterar um
pouco o esquema inicial do RAID, por isto a preocupação em ter referencial
do fabricante, evitando desgaste :-)
Já levando pro lado prático, não sei se um servidor em condições
normais(leia-se, não fazendo swap ou com overload), iria mudar muito com
2xRAM ou 1xRAM ou 1/2vez RAM de SWAP, nunca tive esta curiosidade e também
não tenho meios de testar, mas seria um trabalho interessante para alguém
voltado ao lado de pesquisa, se interessar, fazer e traria muito peso para
estas tomadas de decisões.
Desculpem também se estou fugindo um pouco do tema..
>
> 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!"
>
> -------------------------
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Mais detalhes sobre a lista de discussão freebsd