Obrigado pelas informações.
- Atualmente o sistema gera muitas transações de gravação (necessárias), como também consultas diversas consideradas pesadas e leves; - Monitoro a memória através do TOP, Free e felizmente esse não tem sido o problema pois está dentro da normalidade, e não chega a utilizar swap; - O Sharebuffers em 1024MB optei em função do grande número de consultas que são realizadas (algumas bem grandes); - O autovaccum está desabilitado em função de rodar diariamente (a noite) o vacuum -z -f -v d que através de consultas aqui no fórum poderia substituir o automático, está correto essa afirmação?; - Vou pesquisar um pouco mais como configurar o arquivo SYSCTL.CONF, pois estou perdido nesses parâmetros! - O parâmetro Wormem coloquei alto por relatos de utilização de ordenação, agrupadores.. e como alguns relatórios utilizam muito recurso de ordenação, agrupadores, união, subselects, dump imaginei como importante, mas não sei afirmar ao certo o ganho! - Na verdade tenho operações pesadas de gravação inclusive com transação quando leitura, por isso optei por setar o commit_delay - As chaves estrangeiras e campos de seleções muito usados contém índices, e vou seguir o seu conselho para habilitar stats_block_level e consultar as tabelas internas do banco de modo a visualizar algumas informações como recomenda. - Pelo que entendi o effective_cache_size é extramente útil para a gestão da gravação e utilização de cachê visando desafogar o banco em leituras constantes ao disco pois informações constantemente usadas ficarão em cachê, vou aumentar um pouco mais esse parâmetro para pelo menos 4GB. - Algo que não tenho feito é consultas as tabelas do banco e passarei a fazer isso com freqüência. Uma curiosidade, executei a view pg_stat_user_indexes e consta as colunas idx_scan, idx_tup_read, idx_tup_fetch, a exemplo da tabela de produto ele traz as informações abaixo, o campo que se refere e a chave primária e o primeira estatística 370911787 referente a coluna idx_scan, isso que dizer que mesmo sendo chave primária está sendo realizado uma pesquisa seqüencial? "produto";"produto_pkey";370911787;387804600;353876496 Obrigado! De: JotaComm [mailto:[email protected]] Enviada em: sábado, 15 de agosto de 2009 12:18 Para: [email protected]; Comunidade PostgreSQL Brasileira Assunto: Re: [pgbr-geral] Postgresql 8.2.4 melhorá configuração - Lentidão exporádicas Olá, Gutemberg 2009/8/13 Gutemberg Sarlo - Hotmail <[email protected]> Pessoal, bom dia! Estou com alguns problemas e dificuldade em identificar causas momentanias de lentidão do banco, penso que talvez seja alguma coisa ligada as configurações do banco e semafaros do Linux, gostaria da experiência de vocês para orientação para tentar chegar numa configuração mais equalizada a demanda e equipamento. Você está monitorando o banco e o SO utilizando ferramentas como o sar, iostat, vmstat e top. Através destas ferramentas é possível analisar como está a memória, se ocorre um uso excessivo de memória virtual, como está a cpu e o acesso ao disco. Ao mesmo tempo que você monitora isso você está fazendo uso das views pg_stat_activity para ver que operações estão sendo executados no momento que você identifica que o sistema está apresentendo sinais de lentidão? Você também pode usar a view pg_locks para observar quais os locks existentes em seu banco. Demanda pesada de consultas e transações de manutenção, aplicação web (30%) e client Server (70%). O Vacuum é executado toda madrugada automaticamente via script: su root -c "vacuumdb -U $vU -h $vH -z -f -v -d $vB" >> /home/postgresql/logs/vacuumdb2.txt Você comentou aqui do Vacuum. O Vacuum full você executa com uma certa periodicidade? Se você tiver uma boa configuraçãode max_fsm_pages o vacuum tem um periodicidade de execução menor. Você tem o autovacuum habilitado? Dell PowerEdge 1800 Xeon 8GB - HD scsi (dedicado) OpenSuse 10.3 Postgresql 8.2.4 ============================================================================ == Sysctl.conf ============================================================================ == kernel.shmall = 2147483648 kernel.shmmax = 2147483648 kernel.shmmni = 309329920 kernel.sem = 250 32000 100 128 #kernel.disable_cap_mlock = 1 fs.file-max = 65536 #net.ipv4.ip_local_port_range = 1024 65000 #net.core.rmem_default = 16777216 #1048576 #net.core.rmem_max = 16777216 #1048576 #net.core.wmem_default = 16777216 #262144 net.core.wmem_max = 16777216 #262144 vm.overcommit_memory = 2 vm.overcommit_ratio = 70 ============================================================================ == Postgresql.conf ============================================================================ == max_connections = 220 # (change requires restart) shared_buffers = 1024MB # min 128kB or max_connections*16kB max_prepared_transactions = 3 # can be 0 or more work_mem = 512MB # min 64kB maintenance_work_mem = 1024MB # min 1MB max_fsm_pages = 204800 # min max_fsm_relations*16, 6 bytes each vacuum_cost_delay = 100 # 0-1000 milliseconds //GS 200 fsync = on # turns forced synchronization on or off wal_sync_method = fsync # the default is the first option full_page_writes = on # recover from partial page writes wal_buffers = 128kB # min 32kB commit_delay = 500 # range 0-100000, in microseconds //GS 1000 commit_siblings = 5 # range 1-1000 checkpoint_segments = 32 # in logfile segments, min 1, 16MB each //GS 8 checkpoint_timeout = 5min # range 30s-1h checkpoint_warning = 30s # 0 is off enable_bitmapscan = on enable_hashagg = on enable_hashjoin = on enable_indexscan = on enable_mergejoin = on enable_nestloop = on enable_seqscan = on enable_sort = on enable_tidscan = on random_page_cost = 2.0 # same scale as above //GS 1 - antes 4.0 effective_cache_size = 2GB stats_command_string = on update_process_title = on stats_start_collector = on # needed for block or row stats stats_block_level = off stats_row_level = on autovacuum = off # enable autovacuum subprocess? deadlock_timeout = 1s max_locks_per_transaction = 64 # min 10 _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral Você observou se ao final da operação de vacuum verbose é apresenta uma mensagem relativa ao parâmetro max_fsm_pages. É interessante dar uma olhada nesta informação. Uma informação que não vi no seu arquivo de configuração é a configuração do parâmetro max_fsm_relations. Algumas coisas que me chamaram a atenção foi uma valor extremamente alto para o parâmetro work_mem. Você sabe qual a utilização deste parâmetro? Pelo que entendi seu banco é muito mais de leitura do que escrita. Estou certo? Derrepente se isso for verdade derrepente poderia ser interessante você fazer um aumento para 2GB no tamanho do seu shared_buffers. Outro detalhe que você talvez não precise habiltar é o parâmetro commit_delay e deixar o valor padrão 0, já que seu banco é muito mais leitura do que operações de escrita. Vi que você está com o autovacuum desabilitado. Existe algum motivo especial para isso? Percebi também que o parâmetro stats_block_level está desabilitado, é bastante recomendado que você habilite este parâmetro para on, pois é através dele que você consegue ver informações de como estão as leituras dos blocos do seu banco (pg_statio_user_indexes, pg_stat_database, pg_statio_user_tables). Outro parâmetro que talvez pudesse ser modificado é o effective_cache_size para algo em torno de 4GB. Você conhece a utilização deste parâmetro? Você sabe também como estão a utilização dos seus índices. Imagina que derrepente você tem um tabela bastante grande e uma leitura sequencial esteja sendo feita nela, isso pode comprometer a performance do seu sistema. Na view pg_stat_user_indexes você tem a informação se os seus índices estão ou não sendo utilizados. []s -- JotaComm http://jotacomm.wordpress.com http://www.dextra.com.br/postgres
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
