Em 11 de outubro de 2011 10:29, Guimarães Faria Corcete DUTRA, Leandro < [email protected]> escreveu:
> 2011/10/11 Tiago Valério <[email protected]>: > > > > Um dúvida, tenho um banco de dados versao 9.1 em freebsd com um sistema > de > > arquivos zfs ,para cada 3 discos foram criados pools, para armazenar , > > indice, dados, pg_xlog. > > Hm… faz um tempo já que passou a valer mais a pena confiar num RAID 10 > (1+0) para distribuir a carga. > > Sei que o ZFS tem suas particularidades, mas não sei se vale a pena > fugir muito dos princípios de distribuição de carga entre espelhos, > que é o que o RAID 10 representa. > > > > Pegunta alguém ja usou este sistema de arquivos com banco de dados? > > Sim, em Solaris. Quão maduro está o ZFS em FreeBSD? Na versao no 9 do freebsd ja será um modulo de instalacao. > Eu usaria > somente o que é nativo do FreeBSD se não tivesse certeza da maturidade > do ZFS. Mesmo em GNU/Linux, que tem sistemas de arquivos alternativos > muito mais antigos e usados, como XFS, ReiserFS, JFS e vai por aí > afora, já há muitos anos que a tendência tem sido preferir os sistemas > nativos e integrados, que amadurecem bem rapidamente pela amplitude do > uso e são suportados por amplo ferramental nativo. No caso do > GNU/Linux, todos os desafiantes à evolução de ext2fs até ext4fs, com o > BtrFS aparecendo na curva, têm acabado ficando em nichos. > > > > pois por mais que eu altere os parâmetros de memória no banco > > isto não parece surtir efeito no método de chamada do disco. > > Não creio ter entendido que memória de base tem a ver com método de > chamada de disco. Dá para explicar melhor? > Vou tentar citar a situação que me ocorre.Queria eu utilizar-se de método de chamada do núcleo "wal_sync_method" em write-back , porem nativo de freebsd apenas fsync e open_fsync, embora sabendo das implicações de segurança quanto a falha de hardware por um escrita write-back.Mas a idéia seria justamente trabalhar mais com buffer do disco e tentar fazer com que a escrita seja feita no maior numero de blocos possíveis. Mas acredito que o impacto esteja justamente no metodo fsync pois o wal quer garantir que isto esteja em uma area nao volatil.Correto?Por mais que eu utilize fsync=off . Entao alterei parametros como bgwriter_delay e bgwriter_lru_maxpages para forçar o maior numero de buffers, chegar na area não volátil.Mas tirando alguns snapshots de pg_stat_bgwriter não tive muito sucesso.Os tempos de escrita grandes .Por exemplo: Para update de 10 milhoes de registros 279 sec .Alterando os parametros estes segundos nao parecem tem grandes ganhos nem para mais ou para menos.Percebo pelo zpool iostat que as escritas entre os pools de pg_xlog e dados nao se alteram. Obrigado pela ajuda . > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
