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. > > > Pessoal muitíssimo obrigado pelas informações, foram de grande ajuda... []s Danilo
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
