[FUG-BR] vm.pmap.shpgperproc

[Nilson]

2009/12/29 Emmanuel Alves <manel.pb at gmail.com>:
> 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.
>

Sim, eu acho que é algum problema de configuração no caso
do Mateus e talvez no seu, pois com os 80 milhões de
pv_entries e o software ainda estar pedindo mais, eu só
consigo imaginar que o soft está em pedindo uma pagina
em looping, algo do tipo o pid-pai pedindo uma página pro pid-filho,
e então o filho pedindo a mesma pagina pro pai, que pede a mesma
pro filho, e assim vai indo... e em casa vez ele "aloca" novamente
essa página ao invéz de usar o endereçamento que ele já tem.

Vale lembrar também que quanto maior é essa tabela, mais
lentos ficam os acessos a essas páginas compartilhadas,
pois a cada acesso a uma delas o kernel recebe o endereço
virtual e tem que procurar na tabela qual é o físico.

Com um número assim gigante como o do Mateus, se
quem está devorando as pv_entries for a aplicação
principal da máquina, eu acho que vale mais apena
deixar com o use_physical habilitado, pois "acho" (agora
é achismo mesmo, nunca tive um caso desses de
exaustão de pv_entries pra mitigar) que vai economizar
processamento por não ter que alocar e procurar
coisas dentro dessa tabela.
Porém o "bug" da requisição em loop continuará existindo
da mesma forma, ele está lá em algum lugar loopando,
apenas não existe mais essa alocação de pvs no
meio do caminho.

---
Nilson