Em 8 de agosto de 2014 10:11, Danilo Silva <[email protected]> escreveu:
> > > Em 8 de agosto de 2014 08:25, Matheus de Oliveira < > [email protected]> escreveu: > > >> On Thu, Aug 7, 2014 at 11:52 PM, Danilo Silva <[email protected] >> > wrote: >> >>> Pessoal, segue as configurações do meu ambiente windows >>> >> >> >>> (PostgreSQL 9.2.4): >>> >> >> Atualize para a 9.2.9 imediatamente. >> >> >>> max_connections = 15 >>> shared_buffers = 512MB >>> work_mem = 16MB >>> >> >> Me parece razoável. >> >> >>> maintenance_work_mem = 128MB >>> >> >> Talvez possa tentar aumentar um pouquinho esse aqui, vai ajudar >> autovacuum. >> >> >> >>> fsync = off >>> synchronous_commit = off >>> full_pages_writes = off >>> >> autovacuum = off >>> >> >> Ah?? Quê?? Cuma?? Isso é só pra rodar os testes certo? Desligar esses >> parâmetros é pedir para desastre... Mantenha fsync, synchronous_commit e >> full_page_writes sempre "on" ou terás problema de corrupção de dados, >> correndo o risco de perder seu banco inteiro. Quanto ao autovacuum, se >> rodar ele desabilitado por muito tempo terá muito inchaço nas tabelas, >> inclusive nas de catálogo como o Gurgel sugeriu. A única que está tudo bem >> desabilitar é a synchronous_commit, saiba que o efeito é poder perder >> algumas (últimas) transações que já haviam sido informadas como >> finalizadas/confirmadas ao usuário, mas não há risco de corrupção. >> >> >>> effective_cache_size = 2GB >>> checkpoint_segments = 150 >>> checkpoint_completion_target = 0.9 >>> >> >> Ok. >> >> >>> max_locks_per_transaction = 52048 >>> >>> >> Ou seja, você tem um total de 52048*15=780720 locks disponíveis, o que >> parece ser o suficiente para o pg_dump rodar. Se ainda receber aquele erro, >> aumente ainda mais este valor, pois com acesso concorrente esse limite pode >> ainda sim não ser suficiente. >> >> >> >>> Máquina física windows seven professional, com processador intel core >>> I5-2500K CPU 3.30GHZ (4 cores) e 4 GB de ram, 64 bit >>> >>> configurações do meu ambiente linux (PostgreSQL 9.3.5), consegui uma >>> máquina com linux para os testes :) >>> max_connections = 10 >>> shared_buffers = 1228MB >>> work_mem = 256MB >>> maintenance_work_mem = 128MB >>> >> >> O shared_buffers pode estar muito alto. Eu diria para iniciar com uns >> 512MB. >> >> >>> fsync = off >>> synchronous_commit = off >>> full_pages_writes = off >>> autovacuum = off >>> max_locks_per_transaction = 50064 >>> >> >> Mesmas observações do anterior... >> >> >>> >>> Máquina virtual com Debian 6.0 squeeze, com processador intel xeon CPU >>> E5-2407 2.2GHZ (1 core) e 4 GB de ram, 64 bit >>> >>> Trata-se de um sistema legado desktop, onde estão migrando de banco de >>> dados. O banco de dados antigo é baseado em arquivos .BTR e estão em fase >>> de testes com o postgres, então, no momento, os servidores estão em uso >>> apenas para testes. >>> >>> >> Ok. Tudo bem desabilitar aqueles para testes. Eu deixaria habilitado >> mesmo assim, daí você tem uma noção melhor de como ficará em produção. >> >> Uma dica, para aplicações desktop, fique de olhe e estude a possibilidade >> de uso do pgbouncer. >> >> >> >>> Não é possível utilizar schemas (neste momento) visto isso ser uma >>> particularidade da aplicação, primeiro temos que efetuar a migração para >>> depois alterar a aplicação para utilizar o conceito de schemas. >>> >>> >> Meh... Como a aplicação usa essas tabelas? São sempre usadas todas? Ou é >> algo como cada cliente usa um conjunto de tabelas? Se for, você pode >> separar em esquemas e usar o search_path para o mapeamento. >> >> >> >>> Os testes... >>> >>> Tentei efetuar vacuum full >>> >> >> Não precisa. Perda de tempo... Um simples VACUUM + ANALYZE pode ser >> interessante. >> >> >>> na máquina linux (vacuumdb -v -a -z -f -U postgres), após quase 3 horas >>> de execução ocorreu out of memory, abaixo mensagem da tela >>> DETAIL: 0 dead row versions cannot be removed yet. >>> CPU 0.00s/0.00u sec elapsed 0.00 sec. >>> INFO: analyzing "public.lctoinve_26_2007" >>> INFO: "lctoinve_26_2007": scanned 0 of 0 pages, containing 0 live rows >>> and 0 dead rows; 0 rows in sample, 0 estimated total rows >>> INFO: vacuuming "public.lctos_26_2007" >>> INFO: "lctos_26_2007": found 25830 removable, 25832 nonremovable row >>> versions in 4686 pages >>> DETAIL: 0 dead row versions cannot be removed yet. >>> CPU 3.08s/2.09u sec elapsed 6.50 sec. >>> INFO: analyzing "public.lctos_26_2007" >>> vacuumdb: vacuuming of database "nk" failed: ERROR: out of memory >>> >> >> Diminua o shared_buffers e use uma área de swap nessa máquina. Nunca >> fique (ao menos no Linux) sem área de swap. >> >> Talvez precise de diminuir o work_mem também, me parece um pouco alto. Eu >> começaria com uns 100MB. >> >> >> >>> Tentei efetuar dump, mas também ocorreu out of memory após 32 minutos >>> (detalhe, nem tinha começado a parte dos copy) >>> >>> Mensagem da tela >>> >>> root@debian-x86:~# time /opt/PostgreSQL/9.3/bin/pg_dump -U postgres -x >>> -O -Fc nk > /opt/PostgreSQL/9.3/dump_nk.sql >>> pg_dump: [archiver (db)] query failed: ERROR: out of memory >>> >> >> A mesma recomendação do anterior se aplica aqui. >> >> >> >>> Agora, na máquina windows, o vacuum full está rodando a quase 6 horas, >>> espero que termine... :) >>> >>> >> Eu não esperaria... Ctrl+C no bixo. >> >> >> >>> Creio que a diferença de no linux ocorrer out of memory e no windows não >>> se deve ao fato de que o windows está em uma máquina física e com mais >>> poder de processamento, certo? >>> >>> >> É possível dependendo do virtualizador, mas não consigo garantir. >> >> >> >> >>> >>> Pessoal, desculpa se a minha resposta as perguntas ficou grande, e >>> principalmente por ter respondido como top-posting :) >>> >>> >> Tranquilo. Proveu bastante informações, o que foi bom. >> >> >> > > Como faço um vacuum somente nas tabelas do catálogo? []s Danilo
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
