De: "Marcelo Kruger" <[email protected]> 
Para: [email protected] 
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 000000010000088600000038 

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 
[email protected] 
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral 

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

Responder a