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. Atenciosamente, -- Matheus de Oliveira Analista de Banco de Dados Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
