Leandro Damascena wrote: > postgresql.conf > > max_connections = 1000 Vais utilizar 1000 conexões? Senão sugiro colocar um número médio de conexões + 10/20%.
> maintenance_work_mem = 512MB (as criacoes de tabelas/indices são > particionados e rodam de madrugada, então a criação eh instantanea) Esse valor não precisa ser tão alto. Geralmente esse número fica em torno de 40% a 70% do maior índice ou tabela. Caso esse valor extrapole 1GB, sugiro que considere um valor baixo para esse valor e faça a definição do parâmetro via comando _set_ no ato da execução de alguma manutenção (aka vacuum e/ou analyze). > /* COMMENT */ > Esses dois parametros estão comentados eu fiz inumeros testes e noto que > quando habilito (independente do valor) a performance nas operações de > INSERT/UPDATE caem consideravelmente.. No meu caso eu acho que não será > necessário habilitar, pois os discos são tudo de 15k RPM e o storage tem > 1 cache de 64GB... seria jogar recurso fora, estou certo? > bgwriter_delay = 200 > bgwriter_lru_maxpages = 200 > /* END COMENT */ > Faça mais testes. Acho que você ainda não entendeu para que serve o _background writer_. Eu só mexeria nele após uma sintonia de outros parâmetros. Os valores padrão do 8.3 são razoáveis. > wal_sync_method = open_sync (dentre os diversos modos, alguem sabe me > dizer qual o mais eficaz?) Linux? Nos meus testes foi o que comportou melhor. > wal_buffers = 102400kB Você não precisa disso tudo. Considere manter esse valor na casa das dezenas de megabytes ou menos. > checkpoint_segments = 30 Tenha em mente que quanto maior esse número maior o número de espaço em disco ocupado. > checkpoint_warning = 0 Não faça isso. Ele serve de parâmetro para você saber se o valor de checkpoint_(segments|timeout) está adequado. > log_autovacuum_min_duration = 1s Talvez esse valor esteja muito baixo. > autovacuum_max_workers = 10 Talvez este valor esteja alto. Um bom número é entre 2 e o número de tabelas *muito* utilizadas. > autovacuum_vacuum_threshold = 10000 Esse número está muito alto, não? > autovacuum_vacuum_scale_factor = 1.0 Esse número está muito alto. Ele só executará o vacuum quando a tabela "dobrar" de tamanho. Considere utilizar entre 0.1 e 0.5. <corte> Na sua lista faltou effective_cache_size, random_page_cost e default_statistics_target. >>> shmax = 12GB >>> >> ^^^^^^^ >> Não faça isso. Geralmente não deixo ele ser maior do que 50% da memória. >> > Euler, mas o servidor eh dedicado ao PGSQL, o SO não vai consumir os > outros 4GB restante e ainda tem 2GB de swap. Programas que não sejam do núcleo do PostgreSQL utilizam memória do SO como por exemplo um pg_dump ou pg_restore. -- Euler Taveira de Oliveira http://www.timbira.com/ _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
