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 00000001000008880000005B 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 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 000000010000088600000038 >>>>> >>>>> >>>> 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 >> >> >> _______________________________________________ >> 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
