Em seg, 24 de out de 2016 às 14:27, Luiz Carlos L. Nogueira Jr. < [email protected]> escreveu:
> Flávio, sim, uso -j 6, e temos 8CPUS > Mas nesse caso o -j não serve muito pois temos uma tabela que ocupa quase > 50% do banco. > Enquanto outras threads terminam, a que fica com o COPY dessa tabela fica > rodando, e tem que esperar o final dela pra fazer as tarefas restantes > De -j2 a -j 8 a diferença de tempo é insignificante. > Entendi, você tem um gargalo no COPY o que é bastante estranho. Normalmente, o que pesa na hora de restaurar um dump, é o tempo de criar os índices, daí a opção -j é mais interessante ainda porque mesmo índices numa mesma tabela podem ser criados em paralelo. É esse COPY que pega a maior parte das 2h30 que você cita na sua pergunta? Porque 2h30 só pelo COPY de uma tabela, ou sua tabela tem centenas de gigabytes líquidos (o que é raro) ou você tem um gargalo de I/O importante. Tentou fazer iostat, vmstat ou mesmo um simples top ou htop durante sua restauração? Veja se iowait não está freando suas operações de lote. []s Flavio Gurgel
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
