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