On 02-12-2014 17:43, Alessandro Lima wrote:
>>> Misturar aplicação com banco de dados não é uma boa...
> concordo, mas vai convencer o cliente a gastar mais dinheiro!
>
Não se trata somente de dinheiro. Não analisei o ambiente e isto pode
ser puramente uma possibilidade... A aplicação está lenta porque a
máquina não suporta operar com determinada quantidade de usuários
fazendo tarefas X, Y e Z. Se o recurso computacional é insuficiente, o
cliente precisa aumentar a capacidade ou vai conviver com lentidão e
muita paciência. Jogue as cartas na mesa; a escolha é sempre do cliente. ;)
>>> sugiro que leia sobre como o kernel apresenta esses valores em aplicações
> como top
> cada processo estava com valores distindtos, ou seja, não representavam o
> mesmo processo pai.
>
Cadê a saída? Você ao menos leu a referência?
Eu novamente não entendi a sua colocação. No postgres, toda conexão
possui o mesmo processo pai ('ps faux' que você vai ver o que estou
querendo dizer).
>>> Não entendi a pergunta. Se há memória porque um processo não pode
> utilizá-la?
>>> Sim. Uma simples consulta pode utilizar bem mais do que isso.
> Vou explicar, no meu modesto conhecimento, pensei que o máximo de memória
> ram que o postgres pode usar seria:
> (shared_buffers) + (autovacum_max_workers * maintenance_work_mem) +
> (max_connections + work_mem)
>
Esta conta é inexata. Já vi algumas vezes aqui na lista e nunca tive a
oportunidade de corrigir. Se basear nessa fórmula sem entender como o
seu sistema operacional gerencia memória é o mesmo que colocar uma
chuteira para patinar.
O segundo componente deve ser 'x * mwm' (considerando haver mais objetos
do que max_connections). O terceiro componente na fórmula acima deve ser
'y * wm * n' onde n ⩾ 1 dependendo da complexidade da consulta. Além
disso, você deve considerar 'z * temp_buffers'.
Difícil apresentar algo matematicamente preciso. Vamos para algo mais
aproximado...
Considerando max_connections = a + b,
shared_buffers +
(a + autovacuum_max_workers) * maintenance_work_mem +
b * work_mem * n +
b * temp_buffers
Isso para versão ⩽ 9.3, a versão 9.4 tem autovacuum_work_mem que nos faz
separar o segundo componente. Então:
shared_buffers +
a * maintenance_work_mem +
autovacuum_max_workers * autovacuum_work_mem +
b * work_mem * n +
b * temp_buffers
(A memória dos processos 'background workers' não entram no cálculo).
Nesta fórmula somente o primeiro e o último componente são fixos (mwm,
wm e n podem ser ajustados dinamicamente), ou seja, *não* é possível
fixar a quantidade de RAM total consumida pelo PostgreSQL via
parâmetros. Se mesmo assim, você quiser limitar o efeito do segundo e
terceiro componente ajuste a quantidade de memória por processo no
sistema operacional [1].
> minha intenção era limitar o uso de ram para não usar swap,
> então quando ví um único processo utilizando cerca de 3GB, achei estranho
> dúvida: este tamanho todo de processo poderia ser além dos parâmetros
> citados acima, o cache do s.o.?
>
Você não leu e/ou não entendeu a referência que apresentei... Desses 3
GB, 1 GB é a memória compartilhada ou outros 2 são utilizados pela sua
consulta.
Para não utilizar swap ou limitar o seu uso, você pode configurar o seu
sistema operacional adequadamente [2].
[1] http://www.postgresql.org/docs/9.4/static/kernel-resources.html#AEN28697
[2]
http://www.postgresql.org/docs/9.4/static/kernel-resources.html#LINUX-MEMORY-OVERCOMMIT
--
Euler Taveira Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
