Em 20 de agosto de 2013 22:40, Guimarães Faria Corcete DUTRA, Leandro < l...@dutras.org> escreveu:
> 2013/8/20 Danilo Silva <danilo.dsg.go...@gmail.com>: > > estava tendo em meu ambiente de desenvolvimento, que é o meu notebook, > > somente problema de lentidão, considerando que o ambiente estava em uma > VM > > com 4 GiB de RAM, S.O linux, mais o apache e o banco tinha em torno de 7 > GiB > > de tamanho, ou seja, não ocorria outros problemas. > > > > Recentemente formatei meu notebook e deixei o linux como S.O principal, > > agora continuo com o mesmo ambiente (banco, apache), porém, o notebook > agora > > tem 6 GiB de RAM, e para minha surpresa, a lentidão não existe. > > 2 GiB de memória viva podem fazer muita diferença, mas suspeito que o > principal seja a base direto numa máquina física. Virtualização em PC > costuma ter E/S sofrível. > > > > Eu sei que se a gente efetuar um dump e subir novamente, vai subir um > banco > > totalmente limpo (sem tuplas mortas) e etc, diminuindo até o tamanho do > > banco. > > > > Agora a dúvida: isso não seria facilmente resolvido executando vacuum > full e > > até mesmo um reindex? ou estou enganado? > > Correto. > > Pois é, no servidor produção, que não está em VM e possui 12 GiB de ram, mesmo executando vacuum full, reindexdb, continuo tendo a lentidão. Acho até que estou com a minha memória (a da cabeça mesmo) corrompida, pois lembrei de alguns detalhes importantes: No servidor de produção, apesar do max_connections estar em 70, eu ainda não vi (a olho nú por assim dizer) esse número em conexões simultânea, mas a replicação nativa está ativa. Posso até ativar uma replicação no meu ambiente de desenvolvimento, mas como poderia simular as conexões simultâneas, não só as conexões mas as transações também? []s Danilo
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
