Opa,
Em 20 de janeiro de 2014 12:58, Flavio Henrique Araque Gurgel < [email protected]> escreveu: > O que importa é: qual o tamanho desse arquivo de dump? >> >> O arquivo tem 4.7GB. >> > > Não é grande. > Aposto que essa base em disco não passa dos 100 GiB . Acertou :) > > > Sim, estou usando a opção -j do pg_restore :) >> > > Qual o valor que passou para o -j e quantos núcleos tem a máquina que está > restaurando? Ao todo a máquina tem 24 núcleos. > > > Usar a opção -j do pg_restore ajuda muito. >> >> Verifique em qual parte da restauração está (visão >> pg_stat_activity). Descompacte o arquivo de dump para texto puro e >> veja se falta muita coisa pra acabar. Às vezes não vale a pena >> interromper o processo pra começar de novo. >> >> >> Pela pg_stat_activity não consigo ver onde ele está, só mostrar COPY( >> colunas) FROM stdin; >> > > Nossa, está antes ainda da criação dos índices. > Isso é *muito* estranho. > Qual o sistema de arquivos que está usando e quais as opções de montagem? > Como não foi em quem montou o servidor precisar verificar, acredito que seja XFS. O diretório de dados está todo mapeado dentro de um storage. Houve uma mudança na nossa infra, e agora este storage está virtualizado abaixo de um V7000. > > De qualquer forma, essa demora é normal. >> > > Agora não acho mais normal. Mais que um dia pra um dump de 4,7 GiB e ainda > no COPY, isso *não* é definitivamente normal. > > > []s > Flavio Gurgel > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > Abraços -- JotaComm http://jotacomm.wordpress.com
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
