Olá, 2009/8/17 Gutemberg Sarlo - Hotmail <[email protected]>
> 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?; > Esta sim. Você pode desabilitar o autovacuum e rodar o vacuum manualmente com você está fazendo. > - Vou pesquisar um pouco mais como configurar o arquivo SYSCTL.CONF, pois > estou perdido nesses parâmetros! > Aconselho que você de uma olhada principalmente em shmmax e shmall. > - 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! > O parâmetro work_mem é utilizado para operações de ordenação e agrupamento. Porém, acho que o valor está um pouco alto. Se você roda relatórios pesados mas não a todo o momento você pode alterar o parâmetro na sessão: Por exemplo: SET work_mem TO "10MB"; Ao finalizar a sessão o valor volta para o definido no postgresql.conf. - Na verdade tenho operações pesadas de gravação inclusive com transação > quando leitura, por isso optei por setar o commit_delay > O commit_delay é importante quando você quer atrasar a escrita e colocar mais de uma transação ao mesmo tempo em pg_xlog através de uma chamada fsync. > - 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 > > > Não. O parâmetro idx_scan informa o número de leituras que estão sendo feitas através do uso de índices. Se você quer ver se suas tabelas possuem leituras sequencias você deve olhar a view pg_stat_user_tables e prestar atenção ao parâmetro seq_scan pois ele indica quantas leituras sequencias já ocorreram na sua tabela. > 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 > []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
