Olá, Flávio e Euler

Estou respondendo aos dois juntos :)

Em 17 de maio de 2011 09:53, Flavio Henrique Araque Gurgel <[email protected]
> escreveu:

> > Cenário: Replicação entre duas máquinas de banco de dados na mesma rede,
> > ambas com o mesmo sistema operacional e mesma versão de banco de dados.
> >
> > Parâmetros utilizados no mestre:
> >
> > wal_level = hot_standby
> > checkpoint_segments = 220
> > checkpoint_timeout = 10min
>
> Seu banco escreve tanto assim?
>

Sim. É um banco de dados que trabalha com rastreamento de veículos. Hoje
temos mais de 50 mil veículos ativos enviando posição dos veículos a todo o
momento. Dependendo da configuração do módulo, o veículo pode mandar posição
de 10 em 10 segundos ou de minuto em minuto.

Ainda estou no ambiente de homologação, por isso os valores podem estar um
pouco altos e/ou baixos ainda. Estou tentando chegar a pouco ideal de
configuração.


> Para fazer um bom tuning do checkpoint_segments eu faço assim:
> - mantenho o checkpoint_timeout em 5min (default);
> - ligo log_checkpoints
> - verifico se os checkpoints estão começando por tempo em produção
> normal (fora de cargas de dados);
>

Normalmente eu faço isso também, coloquei mais para fazer testes, ainda não
fechei esta configuração para o servidor de produção.

> - se estão começando por tempo, os checkpoint_segments estão suficientes.
> 220 me parece exagerado, mesmo para cargas altíssimas de escrita. O
> máximo que cheguei foi 150.
>

De acordo com os testes, estou estourando o checkpoint por
checkpoint_segments.

>
> > checkpoint_completion_target = 0.9
>
> Você tem bons discos, suponho. Em discos comuns SAS 15.000 RPM eu
> deixo este cara a 0.8 pra não arriscar que um checkpoint se atrase na
> finalização, ainda mais considerando sua alta carga de escrita.
> Prefiro aumentar um pouco os parâmetros do bgwriter e deixar menos
> dados pro checkpoint. Faz uma baita diferença. Suas taxas de escrita
> estão monitoradas nos discos? Seu pg_xlog está num disco à parte?
>

Sim. Tenho um Storage da família DS3400, com discos SAS de 15K RPM e RAID
10.

Legal. Não tinha pensado neste possibilidade de aumentar o valor do
bgwriter. Farei um teste com isso. Obrigado pela dica.



> > archive_mode = on
> > archive_command = 'rsync -az --remove-sent-files %p
>
> Ooops... por que "--remove-sent-files"?
> Os logs já arquivados estão sendo removidos? Isso pode ser a causa do
> erro que você está vendo. Dá uma olhada, o arquivo que o PostgreSQL tá
> pedindo ainda está no seu diretório de arquivados?
>

Sim. Normalmente eu removo os arquivos que já arquivei e transferi para o
servidor escravo.

Euler, eu havia pensado em fazer a remoção pg_archivecleanup mas acabei não
fazendo. Como tenho apenas 1 servidor escravo usarei a abordagem sugerida.
Obrigado pela dica.




>
> > postgres@ip:/diretorio_logs_transacao/%f'
> >
> > max_wal_senders = 3
>
> Quantos escravos você tem? A relação é 1:1, se são só dois servidores
> (mestre e escravo) você precisa de 1 sender.
>

Concordo com você Flávio. Aqui foi um erro na configuração :(

>
> > wal_keep_segments = 3
>
> Se seus logs estão sendo apagados, com a taxa de escrita que estou
> pressupondo, este parâmetro está baixo.
>

Quando começei a revisar a configuração percebi isso também, mas como estava
assim na origem do meu problema, postei assim mesmo na lista :)

>
> >
> > Parâmetros utilizados no escravo:
> >
> > hot_standby = on
> >
> > E depois as configurações do arquivo recovery.conf.
>
> Passa aqui o recovery.conf pra nós!
>
> >
> > Flávio, o escravo tem acesso sim aos meus logs de transação.
>
> Mas veja se eles não estão sendo apagados pelo seu comando rsync.
>

Farei esta verificação.

Euler, por quanto tempo você acredita ser interessante deixar os logs
arquivados em outro local?

Pessoal, obrigado pelas dicas, sempre aprendo com vocês :)




> []s!
> Flavio
> _______________________________________________
> pgbr-geral mailing list
> [email protected]
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>


Abraços
-- 
JotaComm
http://jotacomm.wordpress.com
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a