Olá, Gutemberg
2009/8/13 Gutemberg Sarlo - Hotmail <gutembergsco...@hotmail.com> > 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 > pgbr-geral@listas.postgresql.org.br > 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 pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
