Grande Gurgel,
Sempre que eu respondo um e-mail aqui na comunidade eu penso: o
professor vai corrigir tudo que eu disse, detalhadamente, e eu vou
passar vergonha (risos).
Longe de me achar "o professor" mas fico lisonjeado.
Agora, vestindo a camisa de "professor" - por que, ó por que, por que
responder em cima de tudo?
Visto que suas explicaçoes são muito boas, gostaria que completasse-as;
por exemplo faltou você dar uma estimativa de quanto devemos deixar
"para o uso do SO e outros programas".
Se for por falta de números, imaginemos um hardware de 96GB de RAM.
Esse é o pensamento da maioria das pessoas aqui: tenho o hardware X com
memória Y e CPU Z.
Isso só importa quando *sabemos* o que estamos fazendo e o que o banco
de dados envolvido faz.
Por exemplo, um banco OLTP puro pode precisar de um montão de CPU rápida
e discos rapidíssimos e bem ajustados enquanto não utiliza quase nada de
memória RAM. Portanto, um servidor com 256 gigabytes de memória não
servirá pra... nada.
Por outro lado, um banco OLAP puro pode aproveitar praticamente 90% dos
256 gigabytes se estiverem disponíveis como cache do S.O. e uma pequena
fatia em work_mem dos diversos processos para ordenação e concatenação.
Portanto, ter um servidor gigantão não serve pra nada se não souber onde
a memória vai ser utilizada.
Siga a regra de ouro do investimento em hardware para banco de dados:
OLTP
- discos
- CPU
- memória
OLAP
- discos
- memória
- CPU
A regra de ouro do shared_buffers (em OLTP verifique se buffers_backend
não está aumentando rapidamente):
OLTP > OLAP
E do work_mem (basicamente, evite temporários grandes, é fácil ver no
log e PgBadger):
OLAP > OLTP
Note que todas as regras de ouro são um primeiro tuning, um indicativo
de caminho a seguir, jamais são números definitivos. Monitore seu banco
de dados em produção para fazer demais ajustes e investimentos.
[]s
Flavio Gurgel
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
