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 000000010000088600000038 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 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
