[FUG-BR] RES: RES: [OT?] SWAP 2x RAM
Patrick Tracanelli
eksffa em freebsdbrasil.com.br
Sexta Novembro 28 12:18:12 BRST 2008
Renato Frederick escreveu:
> 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.
Sim, faz diferença. Não precisei fazer research, na prática exemplo real
hoje tenho meu laptop. Costumo dizer em aula que nunca devemos dar
atenção a informação "quantidade de swap usada". Não importa, a não ser
que esteja crítico demais porque ai o que importa (frequencia de acesso
a disco) começa ficar crítica por estarem associados. Mas o FreeBSD
tende a consumir bastante SWAP em sistemas de alta carga, o que pode
assustar quem ta acostumado com LX ou Windão.
A gente deve se apegar ao uso da SWAP e não espaço em uso. Na prática o
gstat vai mostrar informações da partição de swap, o que importa são o
L(q) (Lenght Queue, tamanho da fila de operações em espera) que sob
nenhuma hipótese deve ser superior a 1 em qualquer situação em um
sistema de produção, e se chegar a 1 tem que ser em "picos" ou situações
esporádicas. L(q) em 1 é o limite da degradação de performance que
afetará de forma geral o sistema. Os campos ms/r e ms/w (da(s)
partição(es) de swap obviamente) também vão informar diretamente a
degradação de performance em "tempo" pro usuário de forma geral do sistema.
E o principal, informação que o gstat não mostra mas o iostat si, é o
svc_t que é o tempo médio das transações. Veja, é o médio. Informação
precisa pra sabermos o impacto que o uso de SWAP está causando ou não no
sistema.
Na prática meu laptop tem inicialmente 1xRAM (sim eu quis poupar espaço
pq tem bastante RAM hehe), se fica com essa quantidade, e minha RAM fica
perto do limite vejo que começo ter uma frequência de acesso a swap,
mesmo com baixo consumo (8%, 12%) de páginas de swap. Não é nada crítico
e acredito que o acesso a SWAP seja preventivo já que o FreeBSD tem
conhecimento de Segment Stack e controle a probabilidade uma página de
memória precisar ser acessada de acordo com a frequencia de uso de
páginas vizinhas ou a proximidade do relacionamento das páginas em
segmento, no momento em que páginas saem do estado "disponivel para
paginar" e entram em wired (vm.stats.vm.v_wire_count), nesse caso a
pagina precisa estar em RAM e não em SWAP mesmo sem uso, ou seja por
precaução e não necessidade.
Criei então um swapfile (swapfile="" no rc.conf) dobrando a SWAP e
apesar do consumo total ficar equivalente em páginas de memoria virtual
alocadas (o que era 12% vai pra 6% ou 7%), o L(q) e o svc_t indicam
menor acesso, de fato acesso só exporádico.
Porque? Porque tomadas de decisão diferente foram feitas :) Curioso
isso. Outra coisa, é tudo muito bem feito. Quando o acesso a SWAP começa
gerar L(q) que chegue em 1 (campo wait no iostat) as páginas "once
wired" nunca são "paged out" porque o FreeBSD sabe que nesse caso
estaria artificialmente causando degradação de performance. As "once
wired" passam a ser "coloridas" (hehehe) como (tornam-se) "perm wired".
O resultado é mais RAM necessária pras aplicações (e menos RAM
disponível para outras coisas), e a primeira "outras coisas" a sentir
efeito são os buffers de acesso a disco (recurso oferecido pelo
UFS_DIRHASH do kernel), ou seja a performance é degradada em relação a
VFS, e podemos medir (visualizar) observando picos e médias inferiores
na utilização do (mib sysctl) vfs.bufspace.
Bem legal isso :D
>
> 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
>
> -------------------------
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
--
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