Re: [pgbr-geral] Lentidão na aplicação do Archive - Stream Replication

2017-08-31 Por tôpico Marcelo Kruger 
Bom dia Flavio,

Neste momento nosso servidor StandBy não está recebendo consultas devido ao
alto delay entre o ultimo archive enviado, e o aplicado no standby. Mas
esta habilitado para receber consultas.

As configurações de max_standby_streaming_delay e max_standby_archive_delay
estão seguindo o padrão do postgres. Não fiz alterações nestes parametros.

 max_standby_archive_delay   | 30s
 max_standby_streaming_delay | 30s

Eles poderiam influenciar?

Quanto as consultas

repositorio=# select * from pg_replication_slots;
  slot_name  | plugin | slot_type | datoid | database | active | active_pid
|   xmin| catalog_xmin | restart_lsn  | confirmed_flush_lsn
-++---++--+++---+--+--+-
 bdreplica01 || physical  ||  | t  |  47368
| 125364835 |  | 928/B400 |

repositorio=# select * from pg_stat_replication;
  pid  | usesysid |   usename   | application_name | client_addr  |
client_hostname | client_port | backend_start |
backend_xmin |   state   | se
nt_location | write_location | flush_location | replay_location |
sync_priority | sync_state
---+--+-+--+--+-+-+---+--+---+---
+++-+---+
 47368 |18025 | replication | walreceiver  | 10.120.5.201 |
|   50464 | 2017-08-29 15:39:31.591119-03 |  |
streaming | 92
9/98687328  | 929/98686000   | 929/98686000   | 88E/91CB7AE0|
  0 | async

O parametro de log checkpoint está habilitado em nosso banco, e a
quantidade de archives gerados simultaneamente é o seguinte.

[root@bdreplica00 config_exporters]# lsof | grep 0 | grep postgres |
grep -v "deleted" | grep pg_xlog | wc -l
169
[root@bdreplica00 config_exporters]# lsof | grep 0 | grep postgres |
grep -v "deleted" | grep pg_xlog | wc -l
159
[root@bdreplica00 config_exporters]# lsof | grep 0 | grep postgres |
grep -v "deleted" | grep pg_xlog | wc -l
189
[root@bdreplica00 config_exporters]# lsof | grep 0 | grep postgres |
grep -v "deleted" | grep pg_xlog | wc -l
209

O consumo do wal_receiver é baixo comparado ao numero de CPUs que temos. O
processo consome em media 20% de CPU em um nucleo. Possuimos 20 nucleos.

12819 postgres  20   0 35,692g   3520   1876 S  19,2  0,0 149:28.23
postgres: wal receiver process   streaming 933/7C8D8000


40604 postgres  20   0 35,686g   3164   1468 D   2,6  0,0 126:44.17
postgres: startup process   recovering 0001088E0097


Os dados do IOSTAT são os seguintes

[root@bdreplica01 config_exporters]# iostat
Linux 3.10.0-327.36.3.el7.x86_64 (bdreplica01) 08/31/2017 _x86_64_ (20 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
   0,260,000,772,970,00   96,01

Device:tpskB_read/skB_wrtn/skB_readkB_wrtn
md02246,70 26805,26 50759,55 18153260865 34375764472

Quanto a escrita e leitura vejo que a mesma não esta saturada. Em nossa
configuração conseguimos atingir 1,5Gb/s de escrita no disco de banco.
Atualmente este disco é um RAID0 de 17 SSDs. O processo de aplicação de
archives esta consumindo proximo a 16Mb/s.

O problema não poderia estar ligado ao tamanho do archive, que no caso é de
16MB. Outro ponto, a blocagem do disco poderia influenciar neste processo
de restore?

Att,


Em 31 de agosto de 2017 09:25, Flavio Henrique Araque Gurgel <
fha...@gmail.com> escreveu:

>
>
> Em qui, 31 de ago de 2017 às 13:24, Daniel Luiz da Silva <
> daniel.si...@ipm.com.br> escreveu:
>
>> *De: *"Marcelo Kruger" <marcelo.kru...@neoway.com.br>
>> *Para: *"Comunidade PostgreSQL Brasileira" <pgbr-geral@listas.postgresql.
>> org.br>
>> *Enviadas: *Quinta-feira, 31 de agosto de 2017 7:42:46
>>
>> *Assunto: *Re: [pgbr-geral]Lentidão na aplicação do Archive -
>> Stream Replication
>>
>> Bom dia Fabio,
>> Creio que tenha me expressado da maneira incorreta. Não faço nenhuma
>> alteração para copia de archives uma vez que todo o pg_xlog é transferido
>> para a outra maquina via WAL Sender sem que tenha que fazer alterações
>> tanto no recovery.conf, quanto no postgres.conf de ambas as maquinas.
>> Criamos um slot e definimos o banco como hot standby, o procedimento que
>> por sua vez fará com que o a replica receba os arquivos da maquina master,
>> e isso esta ocorrendo corretamente e de forma instantanea.
>>
>> Entretanto irei seguir as recomendações passadas por você, e irei testar
>> o procedimento do Euler.
>>
>> Agradeço desde já pela

Re: [pgbr-geral] Lentidão na aplicação do Archive - Stream Replication

2017-08-31 Por tôpico Flavio Henrique Araque Gurgel 
Em qui, 31 de ago de 2017 às 13:24, Daniel Luiz da Silva <
daniel.si...@ipm.com.br> escreveu:

> *De: *"Marcelo Kruger" <marcelo.kru...@neoway.com.br>
> *Para: *"Comunidade PostgreSQL Brasileira" <
> pgbr-geral@listas.postgresql.org.br>
> *Enviadas: *Quinta-feira, 31 de agosto de 2017 7:42:46
>
> *Assunto: *Re: [pgbr-geral]    Lentidão na aplicação do Archive -
> Stream Replication
>
> Bom dia Fabio,
> Creio que tenha me expressado da maneira incorreta. Não faço nenhuma
> alteração para copia de archives uma vez que todo o pg_xlog é transferido
> para a outra maquina via WAL Sender sem que tenha que fazer alterações
> tanto no recovery.conf, quanto no postgres.conf de ambas as maquinas.
> Criamos um slot e definimos o banco como hot standby, o procedimento que
> por sua vez fará com que o a replica receba os arquivos da maquina master,
> e isso esta ocorrendo corretamente e de forma instantanea.
>
> Entretanto irei seguir as recomendações passadas por você, e irei testar o
> procedimento do Euler.
>
> Agradeço desde já pela atenção.
>
> Att,
>
> Em 31 de agosto de 2017 06:45, Fábio Telles Rodriguez <
> fabio.tel...@gmail.com> escreveu:
>
>>
>>
>> Em 30 de agosto de 2017 19:21, Marcelo Kruger <
>> marcelo.kru...@neoway.com.br> escreveu:
>>
>>> Daniel,
>>>
>>> Devido ao archive estar por padrão no pg_xlog não foi necessario
>>> especificar o archive_command.
>>>
>> Você está fazendo confusão! Jamais copie arquivos diretamente para dentro
>> ou para fora do pg_xlog. Deixe que o PostgreSQL gerencie esta área para
>> você.
>>
>> Monte o Standby de acordo com o procedimento normal. Se estiver na
>> dúvida, siga o procedimento do artigo do Euler Taveira em:
>> http://eulerto.blogspot.com.br/2017/02/replicacao-o-que-mudou.html
>>
>
>
> Marcelo,
> Esse artigo explica bem como configurar diferentes cenários de replicação.
> Mas no seu caso, perceba que a princípio, não existe configuração para
> recebimento do slot de replicação. Então algum problema com configuração de
> hardware ou rede, pode estar acontecendo.
>

Gente, vamos todos com muita calma aí. Um monte de informação jogada e
nenhuma direção clara pra identificar o problema. Os artigos enviados estão
ótimos e corretos, mas parece que o OP está seguindo "o manual" e tem uma
replicação bem padrão configurada, considero que esteja correta.

Ao OP, tenho uma única pergunta - essa base standby recebe consultas de
leitura?
Quais são as configurações max_standby_streaming_delay
e max_standby_archive_delay (parece não importante no seu caso esta última)
?

Como está usando slots de replicação, qual o resultado das consultas abaixo
*no servidor mestre* :
TABLE pg_replication_slots;
TABLE pg_stat_replication;

Você tem o parãmetro log_checkpoints habilitado no mestre? Se sim, tem como
fazer um grep checkpoint no seu log pra gente ver o quanto essa base
escreve?

No servidor standby, tem como ver se o processo wal_receiver está
consumindo muita CPU (top, ps) ?
No servidor standby, poderia nos dizer se a utilisação de disco em escrita
está saturada (iostat) ?

[]s
Flavio Gurgel
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Lentidão na aplicação do Archive - Stream Replication

2017-08-31 Por tôpico Daniel Luiz da Silva 



De: "Marcelo Kruger" <marcelo.kru...@neoway.com.br> 
Para: "Comunidade PostgreSQL Brasileira" <pgbr-geral@listas.postgresql.org.br> 
Enviadas: Quinta-feira, 31 de agosto de 2017 7:42:46 
Assunto: Re: [pgbr-geral] Lentidão na aplicação do Archive - Stream Replication 

Bom dia Fabio, 
Creio que tenha me expressado da maneira incorreta. Não faço nenhuma alteração 
para copia de archives uma vez que todo o pg_xlog é transferido para a outra 
maquina via WAL Sender sem que tenha que fazer alterações tanto no 
recovery.conf, quanto no postgres.conf de ambas as maquinas. Criamos um slot e 
definimos o banco como hot standby, o procedimento que por sua vez fará com que 
o a replica receba os arquivos da maquina master, e isso esta ocorrendo 
corretamente e de forma instantanea. 

Entretanto irei seguir as recomendações passadas por você, e irei testar o 
procedimento do Euler. 

Agradeço desde já pela atenção. 

Att, 

Em 31 de agosto de 2017 06:45, Fábio Telles Rodriguez < fabio.tel...@gmail.com 
> escreveu: 





Em 30 de agosto de 2017 19:21, Marcelo Kruger < marcelo.kru...@neoway.com.br > 
escreveu: 

BQ_BEGIN

Daniel, 

Devido ao archive estar por padrão no pg_xlog não foi necessario especificar o 
archive_command. 



Você está fazendo confusão! Jamais copie arquivos diretamente para dentro ou 
para fora do pg_xlog. Deixe que o PostgreSQL gerencie esta área para você. 

Monte o Standby de acordo com o procedimento normal. Se estiver na dúvida, siga 
o procedimento do artigo do Euler Taveira em: 
http://eulerto.blogspot.com.br/2017/02/replicacao-o-que-mudou.html 


-- 
Atenciosamente, 
Fábio Telles Rodriguez 
blog: http:// s avepoint.blog.br 
e-mail / gtalk / MSN: fabio.tel...@gmail.com 
Skype: fabio_telles 

Timbira - A empresa brasileira de Postgres 
http://www.timbira.com.br 

___ 
pgbr-geral mailing list 
pgbr-geral@listas.postgresql.org.br 
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral 

BQ_END



___ 
pgbr-geral mailing list 
pgbr-geral@listas.postgresql.org.br 
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral 


Marcelo, 
Esse artigo explica bem como configurar diferentes cenários de replicação. Mas 
no seu caso, perceba que a princípio, não existe configuração para recebimento 
do slot de replicação. Então algum problema com configuração de hardware ou 
rede, pode estar acontecendo. 
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Lentidão na aplicação do Archive - Stream Replication

2017-08-31 Por tôpico Marcelo Kruger 
Bom dia Fabio,

Creio que tenha me expressado da maneira incorreta. Não faço nenhuma
alteração para copia de archives uma vez que todo o pg_xlog é transferido
para a outra maquina via WAL Sender sem que tenha que fazer alterações
tanto no recovery.conf, quanto no postgres.conf de ambas as maquinas.
Criamos um slot e definimos o banco como hot standby, o procedimento que
por sua vez fará com que o a replica receba os arquivos da maquina master,
e isso esta ocorrendo corretamente e de forma instantanea.

Entretanto irei seguir as recomendações passadas por você, e irei testar o
procedimento do Euler.

Agradeço desde já pela atenção.

Att,

Em 31 de agosto de 2017 06:45, Fábio Telles Rodriguez <
fabio.tel...@gmail.com> escreveu:

>
>
> Em 30 de agosto de 2017 19:21, Marcelo Kruger <
> marcelo.kru...@neoway.com.br> escreveu:
>
>> Daniel,
>>
>> Devido ao archive estar por padrão no pg_xlog não foi necessario
>> especificar o archive_command.
>>
>
> Você está fazendo confusão! Jamais copie arquivos diretamente para dentro
> ou para fora do pg_xlog. Deixe que o PostgreSQL gerencie esta área para
> você.
>
> Monte o Standby de acordo com o procedimento normal. Se estiver na dúvida,
> siga o procedimento do artigo do Euler Taveira em:
> http://eulerto.blogspot.com.br/2017/02/replicacao-o-que-mudou.html
>
>
> --
> Atenciosamente,
> Fábio Telles Rodriguez
> blog: http:// s
> avepoint.blog.br
> e-mail / gtalk / MSN: fabio.tel...@gmail.com
> Skype: fabio_telles
>
> Timbira - A empresa brasileira de Postgres
> http://www.timbira.com.br
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Lentidão na aplicação do Archive - Stream Replication

2017-08-31 Por tôpico Fábio Telles Rodriguez 
Em 30 de agosto de 2017 19:21, Marcelo Kruger 
escreveu:

> Daniel,
>
> Devido ao archive estar por padrão no pg_xlog não foi necessario
> especificar o archive_command.
>

Você está fazendo confusão! Jamais copie arquivos diretamente para dentro
ou para fora do pg_xlog. Deixe que o PostgreSQL gerencie esta área para
você.

Monte o Standby de acordo com o procedimento normal. Se estiver na dúvida,
siga o procedimento do artigo do Euler Taveira em:
http://eulerto.blogspot.com.br/2017/02/replicacao-o-que-mudou.html


-- 
Atenciosamente,
Fábio Telles Rodriguez
blog: http:// s
avepoint.blog.br
e-mail / gtalk / MSN: fabio.tel...@gmail.com
Skype: fabio_telles

Timbira - A empresa brasileira de Postgres
http://www.timbira.com.br
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Lentidão na aplicação do Archive - Stream Replication

2017-08-30 Por tôpico Marcelo Kruger 
Daniel,

Devido ao archive estar por padrão no pg_xlog não foi necessario
especificar o archive_command.

Att,

Em 30 de agosto de 2017 16:37, Daniel Luiz da Silva <daniel.si...@ipm.com.br
> escreveu:

>
>
> --
> *De: *"Marcelo Kruger" <marcelo.kru...@neoway.com.br>
> *Para: *"Comunidade PostgreSQL Brasileira" <pgbr-geral@listas.postgresql.
> org.br>
> *Enviadas: *Quarta-feira, 30 de agosto de 2017 16:23:54
> *Assunto: *Re: [pgbr-geral]    Lentidão na aplicação do Archive -
> Stream Replication
>
> Daniel,
> O arquivo im_the_master é apenas uma trigger para transitar o servidor do
> stand-by para a produção. É um arquivo vazio, nosso processo cria este
> arquivo quando identifica que o servidor principal não esta respondendo.
>
> Quanto ao shared_buffer haviamos lido esta questão do tamanho. Chegamos a
> reduzir o shared, mas o tempo de processamento do archive ficou na mesma
> media de tempo.
>
> Att,
>
> Marcelo,
> Como está o archive_command no slave?
>
> Em 30 de agosto de 2017 16:16, Daniel Luiz da Silva <
> daniel.si...@ipm.com.br> escreveu:
>
>>
>>
>> --
>> *De: *"Marcelo Kruger" <marcelo.kru...@neoway.com.br>
>> *Para: *"Comunidade PostgreSQL Brasileira" <pgbr-geral@listas.postgresql.
>> org.br>
>> *Enviadas: *Quarta-feira, 30 de agosto de 2017 16:03:21
>> *Assunto: *Re: [pgbr-geral]Lentidão na aplicação do Archive -
>> Stream Replication
>>
>> Daniel, quanto a questão do checkpoint_completion_target não havia me
>> atentato. E desta forma justificaria o tempo de descarga dos dados em
>> disco. O shared_buffer é elevado em nosso caso pois nosso processamento de
>> dados exige tal configuração de memoria.
>> Daniel, o arquivo de recovery.conf está da seguinte forma
>>
>> standby_mode   = 'on'
>> primary_slot_name  = 'bdreplica01'
>> primary_conninfo   = 'host=bdreplica00 port=5433 user=replication'
>> trigger_file   = '/var/lib/pgsql/9.6/data/im_the_master'
>>
>> Att,
>>
>> Marcelo,
>>
>> Normalmente não se utiliza o shared_buffer maior que 8GB, justamente
>> porque tem esses malefícios com WAL e recovery caso necessário. Se quiser
>> pesquisar dentro do arquivario do forum PostgreSQL Brasil, existe vários
>> tópicos sobre as desvantagens de ser maior que 8GB. É interessante
>> acompanhar o pg_buffercache do seu cluster, para saber se os arquivos
>> dentro do buffer fica muito tempo, com isso, conseguirá comparar se o
>> tamanho do shared_buffer está suficiente ou não.
>> O que existe dentro do comando im_the_master ?
>>
>> Em 30 de agosto de 2017 15:49, Daniel Luiz da Silva <
>> daniel.si...@ipm.com.br> escreveu:
>>
>>>
>>>
>>> --
>>> *De: *"Marcelo Kruger" <marcelo.kru...@neoway.com.br>
>>> *Para: *"Comunidade PostgreSQL Brasileira" <
>>> pgbr-geral@listas.postgresql.org.br>
>>> *Enviadas: *Quarta-feira, 30 de agosto de 2017 14:55:07
>>> *Assunto: *Re: [pgbr-geral]Lentidão na aplicação do Archive -
>>> Stream Replication
>>>
>>> Daniel, boa tarde.
>>> Para a informação chegar no slave irá demorar mais de 1 dia, uma vez que
>>> tenho 350GB de archives no slave que não foram aplicados ainda. Ou seja, o
>>> processo de WAL Sender envia o arquivo, mas o Slave leva muito tempo para
>>> aplicar na base de dados.
>>>
>>> Aqui existe um detalhe, ela não demorará 1 dia para chegar no slave,
>>> isso será o tempo aproximado para processar o arquivo, o tempo de envio
>>> deverá ser curto.
>>>
>>> Apos finalizar o archive no master o envio para o slave e instantaneo.
>>> Contudo notamos que para gerar um arquivo de 16MB no pg_xlog do master está
>>> levando mais de 10 minutos. E temos operação massiva de inserção e
>>> alteração, que não justificaria a demora para finalizar este archive.
>>>
>>> Para calcular isso terá que acompanhar o checkpoint que ocorre dentro da
>>> base, inclusive, esse cluster está configurado com uma valor bem alto de
>>> shared_buffer, então para ler essa memória e descarregar poderá levar mais
>>> tempo que previsto. Ler esse link  [1]
>>> O seu checkpoint_timeout está em 10 minutos, porém o
>>> checkpoint_completion_target está 0.5, se esse parâmetro estiver com valor
>>> default, como está comentado, e valor no comentário é 0.9, significa que
>>> será feito uma desc

Re: [pgbr-geral] Lentidão na aplicação do Archive - Stream Replication

2017-08-30 Por tôpico Daniel Luiz da Silva 



De: "Marcelo Kruger" <marcelo.kru...@neoway.com.br> 
Para: "Comunidade PostgreSQL Brasileira" <pgbr-geral@listas.postgresql.org.br> 
Enviadas: Quarta-feira, 30 de agosto de 2017 16:23:54 
Assunto: Re: [pgbr-geral] Lentidão na aplicação do Archive - Stream Replication 

Daniel, 
O arquivo im_the_master é apenas uma trigger para transitar o servidor do 
stand-by para a produção. É um arquivo vazio, nosso processo cria este arquivo 
quando identifica que o servidor principal não esta respondendo. 

Quanto ao shared_buffer haviamos lido esta questão do tamanho. Chegamos a 
reduzir o shared, mas o tempo de processamento do archive ficou na mesma media 
de tempo. 

Att, 

Marcelo, 
Como está o archive_command no slave? 

Em 30 de agosto de 2017 16:16, Daniel Luiz da Silva < daniel.si...@ipm.com.br > 
escreveu: 






De: "Marcelo Kruger" < marcelo.kru...@neoway.com.br > 
Para: "Comunidade PostgreSQL Brasileira" < pgbr-geral@listas.postgresql.org.br 
> 
Enviadas: Quarta-feira, 30 de agosto de 2017 16:03:21 
Assunto: Re: [pgbr-geral] Lentidão na aplicação do Archive - Stream Replication 

Daniel, quanto a questão do checkpoint_completion_target não havia me atentato. 
E desta forma justificaria o tempo de descarga dos dados em disco. O 
shared_buffer é elevado em nosso caso pois nosso processamento de dados exige 
tal configuração de memoria. 
Daniel, o arquivo de recovery.conf está da seguinte forma 

standby_mode = 'on' 
primary_slot_name = 'bdreplica01' 
primary_conninfo = 'host=bdreplica00 port=5433 user=replication' 
trigger_file = '/var/lib/pgsql/9.6/data/im_the_master' 

Att, 

Marcelo, 

Normalmente não se utiliza o shared_buffer maior que 8GB, justamente porque tem 
esses malefícios com WAL e recovery caso necessário. Se quiser pesquisar dentro 
do arquivario do forum PostgreSQL Brasil, existe vários tópicos sobre as 
desvantagens de ser maior que 8GB. É interessante acompanhar o pg_buffercache 
do seu cluster, para saber se os arquivos dentro do buffer fica muito tempo, 
com isso, conseguirá comparar se o tamanho do shared_buffer está suficiente ou 
não. 
O que existe dentro do comando im_the_master ? 

Em 30 de agosto de 2017 15:49, Daniel Luiz da Silva < daniel.si...@ipm.com.br > 
escreveu: 

BQ_BEGIN




De: "Marcelo Kruger" < marcelo.kru...@neoway.com.br > 
Para: "Comunidade PostgreSQL Brasileira" < pgbr-geral@listas.postgresql.org.br 
> 
Enviadas: Quarta-feira, 30 de agosto de 2017 14:55:07 
Assunto: Re: [pgbr-geral] Lentidão na aplicação do Archive - Stream Replication 

Daniel, boa tarde. 
Para a informação chegar no slave irá demorar mais de 1 dia, uma vez que tenho 
350GB de archives no slave que não foram aplicados ainda. Ou seja, o processo 
de WAL Sender envia o arquivo, mas o Slave leva muito tempo para aplicar na 
base de dados. 

Aqui existe um detalhe, ela não demorará 1 dia para chegar no slave, isso será 
o tempo aproximado para processar o arquivo, o tempo de envio deverá ser curto. 

Apos finalizar o archive no master o envio para o slave e instantaneo. Contudo 
notamos que para gerar um arquivo de 16MB no pg_xlog do master está levando 
mais de 10 minutos. E temos operação massiva de inserção e alteração, que não 
justificaria a demora para finalizar este archive. 

Para calcular isso terá que acompanhar o checkpoint que ocorre dentro da base, 
inclusive, esse cluster está configurado com uma valor bem alto de 
shared_buffer, então para ler essa memória e descarregar poderá levar mais 
tempo que previsto. Ler esse link [1] 
O seu checkpoint_timeout está em 10 minutos, porém o 
checkpoint_completion_target está 0.5, se esse parâmetro estiver com valor 
default, como está comentado, e valor no comentário é 0.9, significa que será 
feito uma descarga da memória para o disco de arquivos WAL a cada +-5 minutos 
(10 minutos * 0.5), se estiver configurado padrão, e +-9 minutos ( 10 minutos * 
0.9), se configurado dessa forma. É importante intender como funciona esse 
processo. 

Mas existe algum problema na slave ainda. Como está configurado seu 
"recovery.conf"? Esse arquivo deveria ler os arquivos que chega 
instantaneamente. 

[1] https://www.postgresql.org/docs/9.6/static/wal-configuration.html 

Att, 



Em 30 de agosto de 2017 14:31, Daniel Luiz da Silva < daniel.si...@ipm.com.br > 
escreveu: 

BQ_BEGIN




De: "Marcelo Kruger" < marcelo.kru...@neoway.com.br > 
Para: "Comunidade PostgreSQL Brasileira" < pgbr-geral@listas.postgresql.org.br 
> 
Enviadas: Quarta-feira, 30 de agosto de 2017 14:14:04 
Assunto: Re: [pgbr-geral] Lentidão na aplicação do Archive - Stream Replication 

Lucas, boa tarde. 
Não é utilizado Parallel Query no Slave. 

Att, 

Em 30 de agosto de 2017 14:07, Lucas Viecelli < lviecelli...@gmail.com > 
escreveu: 

BQ_BEGIN


BQ_BEGIN


Hoje temos 1,6 dias de lag entre o archive da produção, e o archive da

Re: [pgbr-geral] Lentidão na aplicação do Archive - Stream Replication

2017-08-30 Por tôpico Marcelo Kruger 
Daniel,

O arquivo im_the_master é apenas uma trigger para transitar o servidor do
stand-by para a produção. É um arquivo vazio, nosso processo cria este
arquivo quando identifica que o servidor principal não esta respondendo.

Quanto ao shared_buffer haviamos lido esta questão do tamanho. Chegamos a
reduzir o shared, mas o tempo de processamento do archive ficou na mesma
media de tempo.

Att,

Em 30 de agosto de 2017 16:16, Daniel Luiz da Silva <daniel.si...@ipm.com.br
> escreveu:

>
>
> --
> *De: *"Marcelo Kruger" <marcelo.kru...@neoway.com.br>
> *Para: *"Comunidade PostgreSQL Brasileira" <pgbr-geral@listas.postgresql.
> org.br>
> *Enviadas: *Quarta-feira, 30 de agosto de 2017 16:03:21
> *Assunto: *Re: [pgbr-geral]    Lentidão na aplicação do Archive -
> Stream Replication
>
> Daniel, quanto a questão do checkpoint_completion_target não havia me
> atentato. E desta forma justificaria o tempo de descarga dos dados em
> disco. O shared_buffer é elevado em nosso caso pois nosso processamento de
> dados exige tal configuração de memoria.
> Daniel, o arquivo de recovery.conf está da seguinte forma
>
> standby_mode   = 'on'
> primary_slot_name  = 'bdreplica01'
> primary_conninfo   = 'host=bdreplica00 port=5433 user=replication'
> trigger_file   = '/var/lib/pgsql/9.6/data/im_the_master'
>
> Att,
>
> Marcelo,
>
> Normalmente não se utiliza o shared_buffer maior que 8GB, justamente
> porque tem esses malefícios com WAL e recovery caso necessário. Se quiser
> pesquisar dentro do arquivario do forum PostgreSQL Brasil, existe vários
> tópicos sobre as desvantagens de ser maior que 8GB. É interessante
> acompanhar o pg_buffercache do seu cluster, para saber se os arquivos
> dentro do buffer fica muito tempo, com isso, conseguirá comparar se o
> tamanho do shared_buffer está suficiente ou não.
> O que existe dentro do comando im_the_master ?
>
> Em 30 de agosto de 2017 15:49, Daniel Luiz da Silva <
> daniel.si...@ipm.com.br> escreveu:
>
>>
>>
>> --
>> *De: *"Marcelo Kruger" <marcelo.kru...@neoway.com.br>
>> *Para: *"Comunidade PostgreSQL Brasileira" <pgbr-geral@listas.postgresql.
>> org.br>
>> *Enviadas: *Quarta-feira, 30 de agosto de 2017 14:55:07
>> *Assunto: *Re: [pgbr-geral]Lentidão na aplicação do Archive -
>> Stream Replication
>>
>> Daniel, boa tarde.
>> Para a informação chegar no slave irá demorar mais de 1 dia, uma vez que
>> tenho 350GB de archives no slave que não foram aplicados ainda. Ou seja, o
>> processo de WAL Sender envia o arquivo, mas o Slave leva muito tempo para
>> aplicar na base de dados.
>>
>> Aqui existe um detalhe, ela não demorará 1 dia para chegar no slave, isso
>> será o tempo aproximado para processar o arquivo, o tempo de envio deverá
>> ser curto.
>>
>> Apos finalizar o archive no master o envio para o slave e instantaneo.
>> Contudo notamos que para gerar um arquivo de 16MB no pg_xlog do master está
>> levando mais de 10 minutos. E temos operação massiva de inserção e
>> alteração, que não justificaria a demora para finalizar este archive.
>>
>> Para calcular isso terá que acompanhar o checkpoint que ocorre dentro da
>> base, inclusive, esse cluster está configurado com uma valor bem alto de
>> shared_buffer, então para ler essa memória e descarregar poderá levar mais
>> tempo que previsto. Ler esse link  [1]
>> O seu checkpoint_timeout está em 10 minutos, porém o
>> checkpoint_completion_target está 0.5, se esse parâmetro estiver com valor
>> default, como está comentado, e valor no comentário é 0.9, significa que
>> será feito uma descarga da memória para o disco de arquivos WAL a cada +-5
>> minutos (10 minutos * 0.5), se estiver configurado padrão, e +-9 minutos (
>> 10 minutos * 0.9), se configurado dessa forma. É importante intender como
>> funciona esse processo.
>>
>> Mas existe algum problema na slave ainda. Como está configurado seu
>> "recovery.conf"? Esse arquivo deveria ler os arquivos que chega
>> instantaneamente.
>>
>> [1] https://www.postgresql.org/docs/9.6/static/wal-configuration.html
>>
>> Att,
>>
>>
>>
>> Em 30 de agosto de 2017 14:31, Daniel Luiz da Silva <
>> daniel.si...@ipm.com.br> escreveu:
>>
>>>
>>>
>>> --
>>> *De: *"Marcelo Kruger" <marcelo.kru...@neoway.com.br>
>>> *Para: *"Comunidade PostgreSQL Brasileira" <
>>> pgbr-geral@listas.postgresql.org.br>
>>> *Envia

Re: [pgbr-geral] Lentidão na aplicação do Archive - Stream Replication

2017-08-30 Por tôpico Daniel Luiz da Silva 



De: "Marcelo Kruger" <marcelo.kru...@neoway.com.br> 
Para: "Comunidade PostgreSQL Brasileira" <pgbr-geral@listas.postgresql.org.br> 
Enviadas: Quarta-feira, 30 de agosto de 2017 16:03:21 
Assunto: Re: [pgbr-geral] Lentidão na aplicação do Archive - Stream Replication 

Daniel, quanto a questão do checkpoint_completion_target não havia me atentato. 
E desta forma justificaria o tempo de descarga dos dados em disco. O 
shared_buffer é elevado em nosso caso pois nosso processamento de dados exige 
tal configuração de memoria. 
Daniel, o arquivo de recovery.conf está da seguinte forma 

standby_mode = 'on' 
primary_slot_name = 'bdreplica01' 
primary_conninfo = 'host=bdreplica00 port=5433 user=replication' 
trigger_file = '/var/lib/pgsql/9.6/data/im_the_master' 

Att, 

Marcelo, 

Normalmente não se utiliza o shared_buffer maior que 8GB, justamente porque tem 
esses malefícios com WAL e recovery caso necessário. Se quiser pesquisar dentro 
do arquivario do forum PostgreSQL Brasil, existe vários tópicos sobre as 
desvantagens de ser maior que 8GB. É interessante acompanhar o pg_buffercache 
do seu cluster, para saber se os arquivos dentro do buffer fica muito tempo, 
com isso, conseguirá comparar se o tamanho do shared_buffer está suficiente ou 
não. 
O que existe dentro do comando im_the_master ? 

Em 30 de agosto de 2017 15:49, Daniel Luiz da Silva < daniel.si...@ipm.com.br > 
escreveu: 






De: "Marcelo Kruger" < marcelo.kru...@neoway.com.br > 
Para: "Comunidade PostgreSQL Brasileira" < pgbr-geral@listas.postgresql.org.br 
> 
Enviadas: Quarta-feira, 30 de agosto de 2017 14:55:07 
Assunto: Re: [pgbr-geral] Lentidão na aplicação do Archive - Stream Replication 

Daniel, boa tarde. 
Para a informação chegar no slave irá demorar mais de 1 dia, uma vez que tenho 
350GB de archives no slave que não foram aplicados ainda. Ou seja, o processo 
de WAL Sender envia o arquivo, mas o Slave leva muito tempo para aplicar na 
base de dados. 

Aqui existe um detalhe, ela não demorará 1 dia para chegar no slave, isso será 
o tempo aproximado para processar o arquivo, o tempo de envio deverá ser curto. 

Apos finalizar o archive no master o envio para o slave e instantaneo. Contudo 
notamos que para gerar um arquivo de 16MB no pg_xlog do master está levando 
mais de 10 minutos. E temos operação massiva de inserção e alteração, que não 
justificaria a demora para finalizar este archive. 

Para calcular isso terá que acompanhar o checkpoint que ocorre dentro da base, 
inclusive, esse cluster está configurado com uma valor bem alto de 
shared_buffer, então para ler essa memória e descarregar poderá levar mais 
tempo que previsto. Ler esse link [1] 
O seu checkpoint_timeout está em 10 minutos, porém o 
checkpoint_completion_target está 0.5, se esse parâmetro estiver com valor 
default, como está comentado, e valor no comentário é 0.9, significa que será 
feito uma descarga da memória para o disco de arquivos WAL a cada +-5 minutos 
(10 minutos * 0.5), se estiver configurado padrão, e +-9 minutos ( 10 minutos * 
0.9), se configurado dessa forma. É importante intender como funciona esse 
processo. 

Mas existe algum problema na slave ainda. Como está configurado seu 
"recovery.conf"? Esse arquivo deveria ler os arquivos que chega 
instantaneamente. 

[1] https://www.postgresql.org/docs/9.6/static/wal-configuration.html 

Att, 



Em 30 de agosto de 2017 14:31, Daniel Luiz da Silva < daniel.si...@ipm.com.br > 
escreveu: 

BQ_BEGIN




De: "Marcelo Kruger" < marcelo.kru...@neoway.com.br > 
Para: "Comunidade PostgreSQL Brasileira" < pgbr-geral@listas.postgresql.org.br 
> 
Enviadas: Quarta-feira, 30 de agosto de 2017 14:14:04 
Assunto: Re: [pgbr-geral] Lentidão na aplicação do Archive - Stream Replication 

Lucas, boa tarde. 
Não é utilizado Parallel Query no Slave. 

Att, 

Em 30 de agosto de 2017 14:07, Lucas Viecelli < lviecelli...@gmail.com > 
escreveu: 

BQ_BEGIN


BQ_BEGIN


Hoje temos 1,6 dias de lag entre o archive da produção, e o archive da replica. 

Gostaria de apoio para resolver este problema de lentidão no momento do 
recovery destes archives 

12819 postgres 20 0 35.692g 3552 1908 S 9.3 0.0 57:05.46 postgres: wal receiver 
process streaming 8D8/A623D4B8 
40604 postgres 20 0 35.686g 3184 1500 D 4.7 0.0 76:29.52 postgres: startup 
process recovering 000108860038 




Marcelo, você está usando o recurso de Parallel Query nessa banco Slave? Se 
sim, as consultas são demoradas? 
-- 


Atenciosamente. 

Lucas Viecelli 


___ 
pgbr-geral mailing list 
pgbr-geral@listas.postgresql.org.br 
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral 

BQ_END


Marcelo, 

Faz o seguinte teste, identifica um arquivo WAL gerado dentro da pg_xlog/ no 
server master agora, e acompanha quanto tempo esse arquivo demorar para chegar 
no slave.

Re: [pgbr-geral] Lentidão na aplicação do Archive - Stream Replication

2017-08-30 Por tôpico Marcelo Kruger 
Daniel, note que estamos recebendo um archive muito a frente do que estamos
aplicando.



12819 postgres  20   0 35.692g   3520   1876 S   9.0  0.0  73:08.54
postgres: wal receiver process   streaming 8E6/BF2EC000


40607 postgres  20   0 35.688g   5548   1412 S   4.7  0.0  17:49.45
postgres: checkpointer process


40604 postgres  20   0 35.686g   3160   1468 D   4.3  0.0  87:32.05
postgres: startup process   recovering 00010888005B

O processo de recovering esta levando muito tempo para processar um unico
archive (mais de 10 segundos).

Att,

Em 30 de agosto de 2017 16:03, Marcelo Kruger <marcelo.kru...@neoway.com.br>
escreveu:

> Daniel, quanto a questão do checkpoint_completion_target não havia me
> atentato. E desta forma justificaria o tempo de descarga dos dados em
> disco. O shared_buffer é elevado em nosso caso pois nosso processamento de
> dados exige tal configuração de memoria.
>
> Daniel, o arquivo de recovery.conf está da seguinte forma
>
> standby_mode   = 'on'
> primary_slot_name  = 'bdreplica01'
> primary_conninfo   = 'host=bdreplica00 port=5433 user=replication'
> trigger_file   = '/var/lib/pgsql/9.6/data/im_the_master'
>
> Att,
>
> Em 30 de agosto de 2017 15:49, Daniel Luiz da Silva <
> daniel.si...@ipm.com.br> escreveu:
>
>>
>>
>> --
>> *De: *"Marcelo Kruger" <marcelo.kru...@neoway.com.br>
>> *Para: *"Comunidade PostgreSQL Brasileira" <pgbr-geral@listas.postgresql.
>> org.br>
>> *Enviadas: *Quarta-feira, 30 de agosto de 2017 14:55:07
>> *Assunto: *Re: [pgbr-geral]Lentidão na aplicação do Archive -
>> Stream Replication
>>
>> Daniel, boa tarde.
>> Para a informação chegar no slave irá demorar mais de 1 dia, uma vez que
>> tenho 350GB de archives no slave que não foram aplicados ainda. Ou seja, o
>> processo de WAL Sender envia o arquivo, mas o Slave leva muito tempo para
>> aplicar na base de dados.
>>
>> Aqui existe um detalhe, ela não demorará 1 dia para chegar no slave, isso
>> será o tempo aproximado para processar o arquivo, o tempo de envio deverá
>> ser curto.
>>
>> Apos finalizar o archive no master o envio para o slave e instantaneo.
>> Contudo notamos que para gerar um arquivo de 16MB no pg_xlog do master está
>> levando mais de 10 minutos. E temos operação massiva de inserção e
>> alteração, que não justificaria a demora para finalizar este archive.
>>
>> Para calcular isso terá que acompanhar o checkpoint que ocorre dentro da
>> base, inclusive, esse cluster está configurado com uma valor bem alto de
>> shared_buffer, então para ler essa memória e descarregar poderá levar mais
>> tempo que previsto. Ler esse link  [1]
>> O seu checkpoint_timeout está em 10 minutos, porém o
>> checkpoint_completion_target está 0.5, se esse parâmetro estiver com valor
>> default, como está comentado, e valor no comentário é 0.9, significa que
>> será feito uma descarga da memória para o disco de arquivos WAL a cada +-5
>> minutos (10 minutos * 0.5), se estiver configurado padrão, e +-9 minutos (
>> 10 minutos * 0.9), se configurado dessa forma. É importante intender como
>> funciona esse processo.
>>
>> Mas existe algum problema na slave ainda. Como está configurado seu
>> "recovery.conf"? Esse arquivo deveria ler os arquivos que chega
>> instantaneamente.
>>
>> [1] https://www.postgresql.org/docs/9.6/static/wal-configuration.html
>>
>> Att,
>>
>>
>>
>> Em 30 de agosto de 2017 14:31, Daniel Luiz da Silva <
>> daniel.si...@ipm.com.br> escreveu:
>>
>>>
>>>
>>> --
>>> *De: *"Marcelo Kruger" <marcelo.kru...@neoway.com.br>
>>> *Para: *"Comunidade PostgreSQL Brasileira" <
>>> pgbr-geral@listas.postgresql.org.br>
>>> *Enviadas: *Quarta-feira, 30 de agosto de 2017 14:14:04
>>> *Assunto: *Re: [pgbr-geral]Lentidão na aplicação do Archive -
>>> Stream Replication
>>>
>>> Lucas, boa tarde.
>>> Não é utilizado Parallel Query no Slave.
>>>
>>> Att,
>>>
>>> Em 30 de agosto de 2017 14:07, Lucas Viecelli <lviecelli...@gmail.com>
>>> escreveu:
>>>
>>>>
>>>>> Hoje temos 1,6 dias de lag entre o archive da produção, e o archive da
>>>>> replica.
>>>>>
>>>>> Gostaria de apoio para resolver este problema de lentidão no momento
>>>>> do recovery destes archives
>>>>>
>>>>> 12819 postgres  20   0 35.692g   3

Re: [pgbr-geral] Lentidão na aplicação do Archive - Stream Replication

2017-08-30 Por tôpico Marcelo Kruger 
Daniel, quanto a questão do checkpoint_completion_target não havia me
atentato. E desta forma justificaria o tempo de descarga dos dados em
disco. O shared_buffer é elevado em nosso caso pois nosso processamento de
dados exige tal configuração de memoria.

Daniel, o arquivo de recovery.conf está da seguinte forma

standby_mode   = 'on'
primary_slot_name  = 'bdreplica01'
primary_conninfo   = 'host=bdreplica00 port=5433 user=replication'
trigger_file   = '/var/lib/pgsql/9.6/data/im_the_master'

Att,

Em 30 de agosto de 2017 15:49, Daniel Luiz da Silva <daniel.si...@ipm.com.br
> escreveu:

>
>
> --
> *De: *"Marcelo Kruger" <marcelo.kru...@neoway.com.br>
> *Para: *"Comunidade PostgreSQL Brasileira" <pgbr-geral@listas.postgresql.
> org.br>
> *Enviadas: *Quarta-feira, 30 de agosto de 2017 14:55:07
> *Assunto: *Re: [pgbr-geral]    Lentidão na aplicação do Archive -
> Stream Replication
>
> Daniel, boa tarde.
> Para a informação chegar no slave irá demorar mais de 1 dia, uma vez que
> tenho 350GB de archives no slave que não foram aplicados ainda. Ou seja, o
> processo de WAL Sender envia o arquivo, mas o Slave leva muito tempo para
> aplicar na base de dados.
>
> Aqui existe um detalhe, ela não demorará 1 dia para chegar no slave, isso
> será o tempo aproximado para processar o arquivo, o tempo de envio deverá
> ser curto.
>
> Apos finalizar o archive no master o envio para o slave e instantaneo.
> Contudo notamos que para gerar um arquivo de 16MB no pg_xlog do master está
> levando mais de 10 minutos. E temos operação massiva de inserção e
> alteração, que não justificaria a demora para finalizar este archive.
>
> Para calcular isso terá que acompanhar o checkpoint que ocorre dentro da
> base, inclusive, esse cluster está configurado com uma valor bem alto de
> shared_buffer, então para ler essa memória e descarregar poderá levar mais
> tempo que previsto. Ler esse link  [1]
> O seu checkpoint_timeout está em 10 minutos, porém o
> checkpoint_completion_target está 0.5, se esse parâmetro estiver com valor
> default, como está comentado, e valor no comentário é 0.9, significa que
> será feito uma descarga da memória para o disco de arquivos WAL a cada +-5
> minutos (10 minutos * 0.5), se estiver configurado padrão, e +-9 minutos (
> 10 minutos * 0.9), se configurado dessa forma. É importante intender como
> funciona esse processo.
>
> Mas existe algum problema na slave ainda. Como está configurado seu
> "recovery.conf"? Esse arquivo deveria ler os arquivos que chega
> instantaneamente.
>
> [1] https://www.postgresql.org/docs/9.6/static/wal-configuration.html
>
> Att,
>
>
>
> Em 30 de agosto de 2017 14:31, Daniel Luiz da Silva <
> daniel.si...@ipm.com.br> escreveu:
>
>>
>>
>> ------
>> *De: *"Marcelo Kruger" <marcelo.kru...@neoway.com.br>
>> *Para: *"Comunidade PostgreSQL Brasileira" <pgbr-geral@listas.postgresql.
>> org.br>
>> *Enviadas: *Quarta-feira, 30 de agosto de 2017 14:14:04
>> *Assunto: *Re: [pgbr-geral]Lentidão na aplicação do Archive -
>> Stream Replication
>>
>> Lucas, boa tarde.
>> Não é utilizado Parallel Query no Slave.
>>
>> Att,
>>
>> Em 30 de agosto de 2017 14:07, Lucas Viecelli <lviecelli...@gmail.com>
>> escreveu:
>>
>>>
>>>> Hoje temos 1,6 dias de lag entre o archive da produção, e o archive da
>>>> replica.
>>>>
>>>> Gostaria de apoio para resolver este problema de lentidão no momento do
>>>> recovery destes archives
>>>>
>>>> 12819 postgres  20   0 35.692g   3552   1908 S   9.3  0.0  57:05.46
>>>> postgres: wal receiver process   streaming 8D8/A623D4B8
>>>>
>>>>
>>>> 40604 postgres  20   0 35.686g   3184   1500 D   4.7  0.0  76:29.52
>>>> postgres: startup process   recovering 000108860038
>>>>
>>>>
>>> Marcelo, você está usando o recurso de Parallel Query nessa banco Slave?
>>> Se sim, as consultas são demoradas?
>>> --
>>>
>>> Atenciosamente.
>>>
>>> *Lucas Viecelli*
>>>
>>> <http://www.leosoft.com.br/coopcred>
>>>
>>> ___
>>> pgbr-geral mailing list
>>> pgbr-geral@listas.postgresql.org.br
>>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>>
>>
>> Marcelo,
>>
>> Faz o seguinte teste, identifica um arquivo WAL gerado de

Re: [pgbr-geral] Lentidão na aplicação do Archive - Stream Replication

2017-08-30 Por tôpico Daniel Luiz da Silva 



De: "Marcelo Kruger" <marcelo.kru...@neoway.com.br> 
Para: "Comunidade PostgreSQL Brasileira" <pgbr-geral@listas.postgresql.org.br> 
Enviadas: Quarta-feira, 30 de agosto de 2017 14:55:07 
Assunto: Re: [pgbr-geral] Lentidão na aplicação do Archive - Stream Replication 

Daniel, boa tarde. 
Para a informação chegar no slave irá demorar mais de 1 dia, uma vez que tenho 
350GB de archives no slave que não foram aplicados ainda. Ou seja, o processo 
de WAL Sender envia o arquivo, mas o Slave leva muito tempo para aplicar na 
base de dados. 

Aqui existe um detalhe, ela não demorará 1 dia para chegar no slave, isso será 
o tempo aproximado para processar o arquivo, o tempo de envio deverá ser curto. 

Apos finalizar o archive no master o envio para o slave e instantaneo. Contudo 
notamos que para gerar um arquivo de 16MB no pg_xlog do master está levando 
mais de 10 minutos. E temos operação massiva de inserção e alteração, que não 
justificaria a demora para finalizar este archive. 

Para calcular isso terá que acompanhar o checkpoint que ocorre dentro da base, 
inclusive, esse cluster está configurado com uma valor bem alto de 
shared_buffer, então para ler essa memória e descarregar poderá levar mais 
tempo que previsto. Ler esse link [1] 
O seu checkpoint_timeout está em 10 minutos, porém o 
checkpoint_completion_target está 0.5, se esse parâmetro estiver com valor 
default, como está comentado, e valor no comentário é 0.9, significa que será 
feito uma descarga da memória para o disco de arquivos WAL a cada +-5 minutos 
(10 minutos * 0.5), se estiver configurado padrão, e +-9 minutos ( 10 minutos * 
0.9), se configurado dessa forma. É importante intender como funciona esse 
processo. 

Mas existe algum problema na slave ainda. Como está configurado seu 
"recovery.conf"? Esse arquivo deveria ler os arquivos que chega 
instantaneamente. 

[1] https://www.postgresql.org/docs/9.6/static/wal-configuration.html 

Att, 



Em 30 de agosto de 2017 14:31, Daniel Luiz da Silva < daniel.si...@ipm.com.br > 
escreveu: 






De: "Marcelo Kruger" < marcelo.kru...@neoway.com.br > 
Para: "Comunidade PostgreSQL Brasileira" < pgbr-geral@listas.postgresql.org.br 
> 
Enviadas: Quarta-feira, 30 de agosto de 2017 14:14:04 
Assunto: Re: [pgbr-geral] Lentidão na aplicação do Archive - Stream Replication 

Lucas, boa tarde. 
Não é utilizado Parallel Query no Slave. 

Att, 

Em 30 de agosto de 2017 14:07, Lucas Viecelli < lviecelli...@gmail.com > 
escreveu: 

BQ_BEGIN


BQ_BEGIN


Hoje temos 1,6 dias de lag entre o archive da produção, e o archive da replica. 

Gostaria de apoio para resolver este problema de lentidão no momento do 
recovery destes archives 

12819 postgres 20 0 35.692g 3552 1908 S 9.3 0.0 57:05.46 postgres: wal receiver 
process streaming 8D8/A623D4B8 
40604 postgres 20 0 35.686g 3184 1500 D 4.7 0.0 76:29.52 postgres: startup 
process recovering 000108860038 




Marcelo, você está usando o recurso de Parallel Query nessa banco Slave? Se 
sim, as consultas são demoradas? 
-- 


Atenciosamente. 

Lucas Viecelli 


___ 
pgbr-geral mailing list 
pgbr-geral@listas.postgresql.org.br 
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral 

BQ_END


Marcelo, 

Faz o seguinte teste, identifica um arquivo WAL gerado dentro da pg_xlog/ no 
server master agora, e acompanha quanto tempo esse arquivo demorar para chegar 
no slave. Além disso, faz uma consulta em alguma tabela que está no servidor 
master, recupera algumas linhas, e verifica quanto tempo +- demora para chegar 
essa informação no slave. 

Obrigado. 
___ 
pgbr-geral mailing list 
pgbr-geral@listas.postgresql.org.br 
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral 


___ 
pgbr-geral mailing list 
pgbr-geral@listas.postgresql.org.br 
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral 

BQ_END



___ 
pgbr-geral mailing list 
pgbr-geral@listas.postgresql.org.br 
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral 

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Lentidão na aplicação do Archive - Stream Replication

2017-08-30 Por tôpico Marcelo Kruger 
Daniel, boa tarde.

Para a informação chegar no slave irá demorar mais de 1 dia, uma vez que
tenho 350GB de archives no slave que não foram aplicados ainda. Ou seja, o
processo de WAL Sender envia o arquivo, mas o Slave leva muito tempo para
aplicar na base de dados.

Apos finalizar o archive no master o envio para o slave e instantaneo.
Contudo notamos que para gerar um arquivo de 16MB no pg_xlog do master está
levando mais de 10 minutos. E temos operação massiva de inserção e
alteração, que não justificaria a demora para finalizar este archive.

Att,



Em 30 de agosto de 2017 14:31, Daniel Luiz da Silva <daniel.si...@ipm.com.br
> escreveu:

>
>
> --
> *De: *"Marcelo Kruger" <marcelo.kru...@neoway.com.br>
> *Para: *"Comunidade PostgreSQL Brasileira" <pgbr-geral@listas.postgresql.
> org.br>
> *Enviadas: *Quarta-feira, 30 de agosto de 2017 14:14:04
> *Assunto: *Re: [pgbr-geral]    Lentidão na aplicação do Archive -
> Stream Replication
>
> Lucas, boa tarde.
> Não é utilizado Parallel Query no Slave.
>
> Att,
>
> Em 30 de agosto de 2017 14:07, Lucas Viecelli <lviecelli...@gmail.com>
> escreveu:
>
>>
>>> Hoje temos 1,6 dias de lag entre o archive da produção, e o archive da
>>> replica.
>>>
>>> Gostaria de apoio para resolver este problema de lentidão no momento do
>>> recovery destes archives
>>>
>>> 12819 postgres  20   0 35.692g   3552   1908 S   9.3  0.0  57:05.46
>>> postgres: wal receiver process   streaming 8D8/A623D4B8
>>>
>>>
>>> 40604 postgres  20   0 35.686g   3184   1500 D   4.7  0.0  76:29.52
>>> postgres: startup process   recovering 000108860038
>>>
>>>
>> Marcelo, você está usando o recurso de Parallel Query nessa banco Slave?
>> Se sim, as consultas são demoradas?
>> --
>>
>> Atenciosamente.
>>
>> *Lucas Viecelli*
>>
>> <http://www.leosoft.com.br/coopcred>
>>
>> ___
>> pgbr-geral mailing list
>> pgbr-geral@listas.postgresql.org.br
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>
>
> Marcelo,
>
> Faz o seguinte teste, identifica um arquivo WAL gerado dentro da pg_xlog/
> no server master agora, e acompanha quanto tempo esse arquivo demorar para
> chegar no slave. Além disso, faz uma consulta em alguma tabela que está no
> servidor master, recupera algumas linhas, e verifica quanto tempo +- demora
> para chegar essa informação no slave.
>
> Obrigado.
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Lentidão na aplicação do Archive - Stream Replication

2017-08-30 Por tôpico Daniel Luiz da Silva 



De: "Marcelo Kruger" <marcelo.kru...@neoway.com.br> 
Para: "Comunidade PostgreSQL Brasileira" <pgbr-geral@listas.postgresql.org.br> 
Enviadas: Quarta-feira, 30 de agosto de 2017 14:14:04 
Assunto: Re: [pgbr-geral] Lentidão na aplicação do Archive - Stream Replication 

Lucas, boa tarde. 
Não é utilizado Parallel Query no Slave. 

Att, 

Em 30 de agosto de 2017 14:07, Lucas Viecelli < lviecelli...@gmail.com > 
escreveu: 




BQ_BEGIN


Hoje temos 1,6 dias de lag entre o archive da produção, e o archive da replica. 

Gostaria de apoio para resolver este problema de lentidão no momento do 
recovery destes archives 

12819 postgres 20 0 35.692g 3552 1908 S 9.3 0.0 57:05.46 postgres: wal receiver 
process streaming 8D8/A623D4B8 
40604 postgres 20 0 35.686g 3184 1500 D 4.7 0.0 76:29.52 postgres: startup 
process recovering 000108860038 




Marcelo, você está usando o recurso de Parallel Query nessa banco Slave? Se 
sim, as consultas são demoradas? 
-- 


Atenciosamente. 

Lucas Viecelli 


___ 
pgbr-geral mailing list 
pgbr-geral@listas.postgresql.org.br 
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral 

BQ_END


Marcelo, 

Faz o seguinte teste, identifica um arquivo WAL gerado dentro da pg_xlog/ no 
server master agora, e acompanha quanto tempo esse arquivo demorar para chegar 
no slave. Além disso, faz uma consulta em alguma tabela que está no servidor 
master, recupera algumas linhas, e verifica quanto tempo +- demora para chegar 
essa informação no slave. 

Obrigado. 
___ 
pgbr-geral mailing list 
pgbr-geral@listas.postgresql.org.br 
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral 

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Lentidão na aplicação do Archive - Stream Replication

2017-08-30 Por tôpico Marcelo Kruger 
Lucas, boa tarde.

Não é utilizado Parallel Query no Slave.

Att,

Em 30 de agosto de 2017 14:07, Lucas Viecelli 
escreveu:

>
>> Hoje temos 1,6 dias de lag entre o archive da produção, e o archive da
>> replica.
>>
>> Gostaria de apoio para resolver este problema de lentidão no momento do
>> recovery destes archives
>>
>> 12819 postgres  20   0 35.692g   3552   1908 S   9.3  0.0  57:05.46
>> postgres: wal receiver process   streaming 8D8/A623D4B8
>>
>>
>> 40604 postgres  20   0 35.686g   3184   1500 D   4.7  0.0  76:29.52
>> postgres: startup process   recovering 000108860038
>>
>>
> Marcelo, você está usando o recurso de Parallel Query nessa banco Slave?
> Se sim, as consultas são demoradas?
> --
>
> Atenciosamente.
>
> *Lucas Viecelli*
>
> 
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Lentidão na aplicação do Archive - Stream Replication

2017-08-30 Por tôpico Marcelo Kruger 
Boa tarde Daniel,

O tempo para chegar um arquivo do master para a replica é de milesegundos.
O envio do archive quando gravado no pg_xlog é enviado para a replica
instantaneamente.

O arquivo gerado no pg_xlog da master é recebido na replica e visto da
seguinte forma.

12819 postgres  20   0 35,692g   3572   1928 S   2,7  0,0  65:16.78
postgres: wal receiver process   streaming 8DF/7DD

Quanto ao tempo de atraso ele pode ser calculado da seguinte forma.

SELECT (CASE WHEN pg_last_xlog_receive_location() =
pg_last_xlog_replay_location()
THEN 0
ELSE EXTRACT (EPOCH FROM now() -
pg_last_xact_replay_timestamp())
END) AS log_delay;

Já a movimentação para o PG_XLOG é feita pelo proprio stream replication,
não havendo nenhuma configuração. O trafego destes arquivo para a replica é
feito atravez da configuração recovery.conf.

standby_mode   = 'on'
primary_slot_name  = 'slot'
primary_conninfo   = 'host=hostname port=5433 user=replication
trigger_file   = '/var/lib/pgsql/9.6/data/im_the_master

Att,

Em 30 de agosto de 2017 13:54, Daniel Luiz da Silva  escreveu:

>
> --
> *De: *"Marcelo Kruger" 
> *Para: *pgbr-geral@listas.postgresql.org.br
> *Enviadas: *Quarta-feira, 30 de agosto de 2017 12:09:56
> *Assunto: *[pgbr-geral] Lentidão na aplicação do Archive - Stream
> Replication
>
> Boa tarde a todos,
> Possuimos uma arquitetura na nuvem da Azure com duas maquinas de banco com
> a versão 9.6 do Postgres. Esta estrutura trabalha com uma maquina sendo o
> banco principal, e a outra sendo a replica deste banco. A replicação é de
> forma assincrona e via Stream Replication, utilizando um Slot para
> replicação.
>
> Ambas as maquinas possuem os mesmos recursos de hardware, e as mesmas
> otimizações em SO
>
>
> Disco: 17TB para database, sendo 9TB consumido. Disco é um RAID 0 de
> 17SSDs de 1TB
> 144 GB de memoria
> 20 nucleos de processamento
>
> A maquina principal tem otima performance, enviando os archives do pg_xlog
> em uma rede de banda maxima de 1,5GB/s. Identificamos que não existe
> problema e lentidão no envio e recebimento dos arquivos na replica.
> Entretando quando o postgres replicado inicia o processo de recovery destes
> archives demora um tempo muito elevado, estando em media 15 segundos para
> processar um archive. Isso esta causando uma diferença de dados entre os
> bancos muito elevada, fazendo desta forma que a replicação nunca finalize o
> processamento dos archives.
>
> Hoje temos 1,6 dias de lag entre o archive da produção, e o archive da
> replica.
>
> Gostaria de apoio para resolver este problema de lentidão no momento do
> recovery destes archives
>
> 12819 postgres  20   0 35.692g   3552   1908 S   9.3  0.0  57:05.46
> postgres: wal receiver process   streaming 8D8/A623D4B8
>
>
> 40604 postgres  20   0 35.686g   3184   1500 D   4.7  0.0  76:29.52
> postgres: startup process   recovering 000108860038
>
> Segue abaixo configuração do postgresql.conf da replica.
>
> listen_addresses = '*'
> port = 5433
> max_connections = 2000
> superuser_reserved_connections = 3
> shared_buffers = 35257MB
> work_mem = 18051kB
> maintenance_work_mem = 8GB
> #autovacuum_work_mem = 4GB
> max_stack_depth = 5MB
> dynamic_shared_memory_type = posix
> vacuum_cost_delay = 20
> vacuum_cost_limit = 200
> bgwriter_delay = 10ms
> bgwriter_lru_maxpages = 700
> bgwriter_lru_multiplier = 2.0
> fsync = off
> synchronous_commit = off
> full_page_writes = off
> wal_buffers = 16MB
> wal_writer_delay = 1ms
> checkpoint_timeout = 10min
> max_wal_size = 8GB
> min_wal_size = 4GB
> #checkpoint_completion_target = 0.9
> effective_cache_size = 105772MB
> default_statistics_target = 500
> log_destination = 'csvlog'
> logging_collector = off
> log_directory = 'pg_log'
> log_filename = 'postgresql-%w.log'
> log_file_mode = 0640
> log_truncate_on_rotation = on
> log_rotation_age = 1d
> log_rotation_size = 600MB
> log_min_duration_statement = 0
> log_checkpoints = on
> log_connections = off
> log_disconnections = off
> log_duration = on
> log_line_prefix = '%t [%p]: [%l-1] db=%d,user=%u,app=%a,client=%h'
> log_lock_waits = on
> log_timezone = 'Brazil/East'
> autovacuum = on
> log_autovacuum_min_duration = -1
> autovacuum_max_workers = 8
> autovacuum_naptime = 30s
> autovacuum_vacuum_threshold = 20
> autovacuum_analyze_threshold = 20
> autovacuum_vacuum_scale_factor = 0.2
> autovacuum_analyze_scale_factor = 0.1
> autovacuum_vacuum_cost_delay = -1
> datestyle = 'iso, mdy'
> timezone = 'Brazil/East'
> lc_messages = 'en_US.UTF-8'
> lc_monetary = 'en_US.UTF-8'
> lc_numeric = 'en_US.UTF-8'
> lc_time = 'en_US.UTF-8'
> default_text_search_config = 'pg_catalog.english'
> max_locks_per_transaction = 256
> pgpool.pg_ctl = '/usr/pgsql-9.6/bin/pg_ctl'
> huge_pages=on
> hot_standby = on
> hot_standby_feedback = off
> wal_receiver_timeout = 0
>
>
> Att,
>
> Marcelo,
>
> Acho que primeiramente teria que

Re: [pgbr-geral] Lentidão na aplicação do Archive - Stream Replication

2017-08-30 Por tôpico Lucas Viecelli 
>
>
> Hoje temos 1,6 dias de lag entre o archive da produção, e o archive da
> replica.
>
> Gostaria de apoio para resolver este problema de lentidão no momento do
> recovery destes archives
>
> 12819 postgres  20   0 35.692g   3552   1908 S   9.3  0.0  57:05.46
> postgres: wal receiver process   streaming 8D8/A623D4B8
>
>
> 40604 postgres  20   0 35.686g   3184   1500 D   4.7  0.0  76:29.52
> postgres: startup process   recovering 000108860038
>
>
Marcelo, você está usando o recurso de Parallel Query nessa banco Slave? Se
sim, as consultas são demoradas?
-- 

Atenciosamente.

*Lucas Viecelli*


___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Lentidão na aplicação do Archive - Stream Replication

2017-08-30 Por tôpico Daniel Luiz da Silva 


De: "Marcelo Kruger"  
Para: pgbr-geral@listas.postgresql.org.br 
Enviadas: Quarta-feira, 30 de agosto de 2017 12:09:56 
Assunto: [pgbr-geral] Lentidão na aplicação do Archive - Stream Replication 

Boa tarde a todos, 
Possuimos uma arquitetura na nuvem da Azure com duas maquinas de banco com a 
versão 9.6 do Postgres. Esta estrutura trabalha com uma maquina sendo o banco 
principal, e a outra sendo a replica deste banco. A replicação é de forma 
assincrona e via Stream Replication, utilizando um Slot para replicação. 

Ambas as maquinas possuem os mesmos recursos de hardware, e as mesmas 
otimizações em SO 


Disco: 17TB para database, sendo 9TB consumido. Disco é um RAID 0 de 17SSDs de 
1TB 
144 GB de memoria 
20 nucleos de processamento 

A maquina principal tem otima performance, enviando os archives do pg_xlog em 
uma rede de banda maxima de 1,5GB/s. Identificamos que não existe problema e 
lentidão no envio e recebimento dos arquivos na replica. Entretando quando o 
postgres replicado inicia o processo de recovery destes archives demora um 
tempo muito elevado, estando em media 15 segundos para processar um archive. 
Isso esta causando uma diferença de dados entre os bancos muito elevada, 
fazendo desta forma que a replicação nunca finalize o processamento dos 
archives. 

Hoje temos 1,6 dias de lag entre o archive da produção, e o archive da replica. 

Gostaria de apoio para resolver este problema de lentidão no momento do 
recovery destes archives 

12819 postgres 20 0 35.692g 3552 1908 S 9.3 0.0 57:05.46 postgres: wal receiver 
process streaming 8D8/A623D4B8 
40604 postgres 20 0 35.686g 3184 1500 D 4.7 0.0 76:29.52 postgres: startup 
process recovering 000108860038 

Segue abaixo configuração do postgresql.conf da replica. 

listen_addresses = '*' 
port = 5433 
max_connections = 2000 
superuser_reserved_connections = 3 
shared_buffers = 35257MB 
work_mem = 18051kB 
maintenance_work_mem = 8GB 
#autovacuum_work_mem = 4GB 
max_stack_depth = 5MB 
dynamic_shared_memory_type = posix 
vacuum_cost_delay = 20 
vacuum_cost_limit = 200 
bgwriter_delay = 10ms 
bgwriter_lru_maxpages = 700 
bgwriter_lru_multiplier = 2.0 
fsync = off 
synchronous_commit = off 
full_page_writes = off 
wal_buffers = 16MB 
wal_writer_delay = 1ms 
checkpoint_timeout = 10min 
max_wal_size = 8GB 
min_wal_size = 4GB 
#checkpoint_completion_target = 0.9 
effective_cache_size = 105772MB 
default_statistics_target = 500 
log_destination = 'csvlog' 
logging_collector = off 
log_directory = 'pg_log' 
log_filename = 'postgresql-%w.log' 
log_file_mode = 0640 
log_truncate_on_rotation = on 
log_rotation_age = 1d 
log_rotation_size = 600MB 
log_min_duration_statement = 0 
log_checkpoints = on 
log_connections = off 
log_disconnections = off 
log_duration = on 
log_line_prefix = '%t [%p]: [%l-1] db=%d,user=%u,app=%a,client=%h' 
log_lock_waits = on 
log_timezone = 'Brazil/East' 
autovacuum = on 
log_autovacuum_min_duration = -1 
autovacuum_max_workers = 8 
autovacuum_naptime = 30s 
autovacuum_vacuum_threshold = 20 
autovacuum_analyze_threshold = 20 
autovacuum_vacuum_scale_factor = 0.2 
autovacuum_analyze_scale_factor = 0.1 
autovacuum_vacuum_cost_delay = -1 
datestyle = 'iso, mdy' 
timezone = 'Brazil/East' 
lc_messages = 'en_US.UTF-8' 
lc_monetary = 'en_US.UTF-8' 
lc_numeric = 'en_US.UTF-8' 
lc_time = 'en_US.UTF-8' 
default_text_search_config = 'pg_catalog.english' 
max_locks_per_transaction = 256 
pgpool.pg_ctl = '/usr/pgsql-9.6/bin/pg_ctl' 
huge_pages=on 
hot_standby = on 
hot_standby_feedback = off 
wal_receiver_timeout = 0 


Att, 

Marcelo, 

Acho que primeiramente teria que intender o local do problema. O arquivo WAL 
quando é replicado do servidor master para o servidor slave, demora quanto 
tempo para chegar no servidor slave? Nesse modo, nunca irá termina o archive, 
ele sempre estará aguardando o arquivo WAL, caso queira observar no log do 
postgres slave ele solta a mensagem aguardando o arquivo "XYZ", até receber 
esse arquivo. Como foi calculado esse atraso em 1.6 dias? Existe um outro 
problema que dependedo do volume de gravação que recebe o servidor master, caso 
o volume seja muito alto, ele seguirá o caminho comum até chegar no servidor 
slave, levará um tempo. O que executa no parâmetro archive_command ? Como 
funciona a movimentação da pasta pg_xlog para pasta archive? Como está o 
parâmetro max_wal_senders ? 

Obrigado. 

___ 
pgbr-geral mailing list 
pgbr-geral@listas.postgresql.org.br 
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral 

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral