[FUG-BR] vm.pmap.shpgperproc

[Emmanuel Alves]

Parabéns Nilson pela detalhada explicação.

Esta mensagem acontece comigo tb, o warning gerado no log messages. No meu
caso é um servidor muito requisitado com apache + mysql.

Será que alguma configuração no apache acarretou isto? Há algum problema se
ignorar a mensagem, visto que meu servidor está se comportando normalmente e
sem instabilidades.

[]s

Emmanuel Alves
manel.pb em gmail.com

---------------------------------------------------------------------
Twitter: http://www.twitter.com/emartsnet
Linked In: http://www.linkedin.com/in/emartsnet


2009/12/29 Nilson <nilson em forge.com.br>

> 2009/12/28 mateusgra <mateusgra em bol.com.br>:
> >   Â
> >  Valores Atuais.
> >   vm.pmap.shpgperproc: 6.793
> >   vm.pmap.pv_entry_max: 50.000.000
> >   Li em uma lista que tem que colocar o options
> PMAP_SHPGPERPROC=1024 no
> >   conf e compilar o kernel novamente.
>
> Se o seu limite de SHared PaGes PER PROCcess já está
> em 6793 e o kernel tá berrando, como é que colocar 1024
> vai resolver? Coloca uns 8k ou 16k. Depende da finalidade
> pra qual você está usando essa quantidade absurda de
> memória compartilhada.
>
>
> >   Fiz isso em uma VM de teste e deu certo, mas queria entender porque
> >   com  kern.ipc.shm_use_phys=1 o alerta "Approaching the limit on PV
> >   entries, consider increasing either the vm.pmap.shpgperproc or the
> >   vm.pmap.pv_entry_max sysctl" não aparece.
>
> É por que cada vez que algum processo quer alocar memória,
> o kernel tem que dar um endereço de memória pro programa:
> "toma, esse é o endereço do bloco q tu me pediu".
> Só que cada arquitetura de computador (o funcionamento
> físico mesmo) é de um jeito, uns melhores outros piores,
> então o pessoal inventou o mapa PV (Physical to Virtual),
> assim o kernel entrega um endereço VIRTUAL pro programa
> e mapeia na sua PMAP onde fica físicamente aquela
> informação. Isso tem um camalhaço de vantagens pro
> kernel, por que ele pode ficar mudando tua informação
> de lugar sempre que ele precisar ou quiser, e aquele
> endereço virtual que ele deu lá no começo continua
> o mesmo. Entendeu até aqui?
>
> Isso tudo era sobre memória "comum", dai um pessoal
> que não tinha umas ideias muito boas de programação
> achou q toda essa babaquisse de restrições de memória
> no unix era uma puta enchessão de saco pra programar
> coisas complexas, então inventaram um lixão chamado
> SHARED MEMORY. Quando um processo aloca memória
> compartilhada, o kernel também entrega um endereço
> virtual, e quando outro processo quer acessar aquele
> MESMO PEDAÇO de memória compartilhada, o kernel
> entrega OUTRO ENDEREÇO virtual que é só mais uma
> entrada na tabela de pvs (a tal pv_entry) que aponta pro
> mesmo lugar físico, só que tem outras propriedades, como
> outro dono, ou somente leitura, etc...
>
> Então quando você usa aquele "shm_use_phys" você
> está dizendo pro kernel parar com essa "baboseira" de
> virtual, por que o software que você quer rodar é POWER,
> é a coisa MAIS IMPORTANTE do computador, e que
> SHM de agora em diante tem que ser sempre PHYSICAL.
>
> Assim, não tem mais entradas PV pra todo bendito
> processo que quer compartilhar aquele pedaço, o kernel
> já diz direto fisicamente onde fica e que se dane...
>
> Isso tem a vantagem de acabar com esse overhead
> (penso que é pequeno...) do gerenciador de memória,
> e como desvantagem a limitação da quantidade de
> restrições que podem ser impostas a essas páginas,
> e a PIOR de todas é que essas páginas compartilhadas
> JAMAIS poderão ser mandadas pra memória virtual (SWAP).
>
> Vira memória presa pra sempre.
>
> >   O que siginifica o PMAP_SHPGPERPROC ?
>
> Significam PMAP = Physical MAP (Mapa da memória física
> do computador), e o SHPGPERPROC é a quantidade máxima
> de páginas de memória compartilhada que UM único processo
> pode ser dono.
>
> > Não tem como mudar ele sem ter
> >   que recompilar o kernel ?
> >   Ja coloquei vm.pmap.shpgperproc: 12.000 e vm.pmap.pv_entry_max:
> >   80.000.000, mesmo a mensagem continua.
>
> No /boot/loader.conf você deve poder mudar esses valores
> tranquilamente, só tendo que rebootar pra entrarem em efeito.
>
> Acho que fiz a caca de mandar um email pela metade,
> não sei se foi, mas o que vale é esse. Malditos atalhos de
> teclado do gmail.
>
> E pra finalizar, que mal lhe pergunte: que software faminto
> por memória compartilhada tas rodando? PostgreSQL?
>
> ---
> Nilson
> -------------------------
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>