Em 29 de julho de 2011 10:47, Emanuel Araújo <[email protected]> escreveu:
> Obrigado Fabio, > > > >> Desligar o FSYNC equivale a não ter mais ACID, não ter um banco >> transacional. Toda vez que você realiza um COMMIT, um registro precisa ser >> gravado no WAL. Se você desligar o FSYNC o SO não vai mais esperar a >> gravação terminar para liberar o seu COMMIT. Resultado: operações de DML >> decolam. Mas.... com um processo de COMMIT assíncrono, você pode corromper o >> WAL em caso de falha de hardware/software/faxineira-puxa-cabos. >> >> > Então apenas para concretizar, o processo de checkpoint continuará > normalmente e o que vai vai ocorrer é apenas a não espera pela gravação do > arquivo de log, ele simplesmente libera o commit antes de gravar no LOG, ou > seja, fica em memória ... > Exatamente, fica em memória. > > em que momento ele pega o que foi gerado em memória e baixa para o LOG? no > checkpoint mesmo? Eu tenho como mandar para base antes de arquivar o LOG? > Vai para o log logo após o commit, mas a transação não espera a gravação terminar para liberar a aplicação. Note que o CHECKPOINT e o LOG são coisas distintas. O único ponto de contato entre o CHECKPOINT e o LOG é que antes de apagar um log do WAL, o banco precisa ter certeza de que as alterações lá contidas já foram consolidadas em disco. Em geral, o CHECKPOINT roda em segundo plano continuamente. Mas.... em algumas rajadas de alterações, todos os logs do WAL enchem rapidamente e um CHECKPOINT completo acaba ocorrendo. Quando isso ocorre, você percebe que as alterações no banco congelam até o CHECKPOINT terminar. Por isso é importante ter um número razoável de segmentos do WAL. A instalação padrão vem com apenas 3 segmentos, que é algo ridiculamente pequeno para sistemas OLTP. > > > >> Muita gente desliga o FSYNC antes de uma carga mais pesada. A partir da >> versão 9.1 será possível eleger tabelas no modo NOLOGGING. Estas não irão >> gerar registros no WAL. Uma ótima pedida para cargas temporárias e "tabelas >> temporárias globais". >> >> > Vai ser muito bom ter esse recurso no postgreSQL. > Sim, mas tem de utilizar com cuidado para não perder o emprego... :-P > > >> Agora, se o seu problema é performance em leitura, desligar o FSYNC não >> vai mudar o desempenho. >> >> > Meu caso não é leitura. > Recomento o livro do Gregory Smith para você se aprofundar nos seus estudos, ou contratar um DBA... > > Obrigado. > > > -- > *Atenciosamente, > > Emanuel Araújo* > http://eacshm.wordpress.com/ > * > * > *Linux Certified > LPIC-1* > > > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > -- Atenciosamente, Fábio Telles Rodriguez blog: http://www.midstorm.org/~telles/ e-mail / gtalk / MSN: [email protected] Skype: fabio_telles
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
