[FUG-BR] RES: RES: [OT?] SWAP 2x RAM
Patrick Tracanelli
eksffa em freebsdbrasil.com.br
Sexta Novembro 28 12:27:27 BRST 2008
Patrick Tracanelli escreveu:
> 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
Alias pra aquelas situações que o usuário vem de Linux e olha o top do
FreeBSD e se assusta e não tem outra forma de saber como está o consumo
de memória, segue um scriptinho que usamos internamente:
%svn cat https://svn.bh/svn/bsdapps/trunk/bsdapps/bin/memory-status
#!/bin/sh
# Patrick Tracanell <eksffa em freebsdbrasil.com.br>
#
# Obtem informacoes de consumo de memoria e apresenta-as de diversas formas.
#
# Usamos para gerar graficos mem stats no BSDAPPS mas
# pode tambem ser util para tarefas do dia-a-dia quando o top(1) nao
# for muito claro.
#
#
memAll=$(((`sysctl -n vm.stats.vm.v_page_count` * `sysctl -n
hw.pagesize`)/1024))
physReal=$(((`sysctl -n hw.physmem`)/1024))
memCached=$(((`sysctl -n vm.stats.vm.v_cache_count` * `sysctl -n
hw.pagesize`)/1024))
memBuffer=$(((`sysctl -n vfs.bufspace`)/1024))
memFree=$(((`sysctl -n vm.stats.vm.v_free_count` * `sysctl -n
hw.pagesize`)/1024))
availReal=$(($memFree + $memCached))
totalSwap=`swapinfo -k | awk '{getline 2;print $2}'`
usedSwap=`swapinfo -k | awk '{getline 2;print $3}'`
availSwap=`swapinfo -k | awk '{getline 2;print $4}'`
usedReal=$((($physReal - ($availReal + $memBuffer + $memCached))))
echo memAll: $memAll
echo totalReal: $physReal # totalReal
echo memCached: $memCached
echo memBuffer: $memBuffer
echo memFree: $memFree
echo availReal: $availReal
echo totalSwap: $totalSwap
echo usedSwap: $usedSwap
echo availSwap: $availSwap
echo usedReal: $usedReal
Tem também algo bem bonitinho e similar (apesar de não ter informações
fundamentais como MemoryBuffer) num script perl feito pelo rse@:
http://people.freebsd.org/~rse/dist/freebsd-memory
>
>> 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