Re: performance database for backup/restore

From: Jeison Bedoya <jeisonb(at)audifarma(dot)com(dot)co>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: performance database for backup/restore
Date: 2013-05-21 20:03:59
Message-ID: 519BD32F.8040201@audifarma.com.co
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

hi jeff thanks by your answer, when you say "database objects" you
talking about the tables?, because i have 1782 tables in my database.

Umm, my boottleneck not is on CPU because the top don´t show something
about that, the memory is used 30%, and the IO not have problem, because
the Fiber channel SAN have capacity of 8GB and tthe i/o transfer to the
disk is no Upper to 1 GB.

can you explainme again how do you do a 6bg/min for pd_dump

thanks

Atentamente,

JEISON BEDOYA DELGADO
Adm. Servidores y Comunicaciones
AUDIFARMA S.A.

El 21/05/2013 11:11 a.m., Jeff Janes escribió:
> 2013/5/21 Jeison Bedoya <jeisonb(at)audifarma(dot)com(dot)co
> <mailto:jeisonb(at)audifarma(dot)com(dot)co>>
>
> Hi people, i have a database with 400GB running in a server with
> 128Gb RAM, and 32 cores, and storage over SAN with fiberchannel,
> the problem is when i go to do a backup whit pg_dumpall take a lot
> of 5 hours, next i do a restore and take a lot of 17 hours, that
> is a normal time for that process in that machine? or i can do
> something to optimize the process of backup/restore.
>
>
> How many database objects do you have? A few large objects will dump
> and restore faster than a huge number of smallish objects.
>
> Where is your bottleneck? "top" should show you whether it is CPU or IO.
>
> I can pg_dump about 6GB/minute to /dev/null using all defaults with a
> small number of large objects.
>
> Cheers,
>
> Jeff
>
> --
> NOTA VERDE:
> No imprima este correo
> a menos que sea absolutamente necesario.
> Ahorre papel, ayude a salvar un arbol.
>
> --------------------------------------------------------------------
> Este mensaje ha sido analizado por *MailScanner*
> <http://www.mailscanner.info/>
> en busca de virus y otros contenidos peligrosos,
> y se considera que esta limpio.
>
> --------------------------------------------------------------------
> Este texto fue anadido por el servidor de correo de Audifarma S.A.:
>
> Las opiniones contenidas en este mensaje no necesariamente coinciden
> con las institucionales de Audifarma. La informacion y todos sus
> archivos Anexos, son confidenciales, privilegiados y solo pueden ser
> utilizados por sus destinatarios. Si por error usted recibe este
> mensaje, le ofrecemos disculpas, solicitamos eliminarlo de inmediato,
> notificarle de su error a la persona que lo envia y abstenerse de
> utilizar su contenido.

--
NOTA VERDE:
No imprima este correo a menos que sea absolutamente necesario.
Ahorre papel, ayude a salvar un arbol.

--------------------------------------------------------------------
Este mensaje ha sido analizado por MailScanner
en busca de virus y otros contenidos peligrosos,
y se considera que esta limpio.

--------------------------------------------------------------------
Este texto fue anadido por el servidor de correo de Audifarma S.A.:

Las opiniones contenidas en este mensaje no necesariamente coinciden
con las institucionales de Audifarma. La informacion y todos sus
archivos Anexos, son confidenciales, privilegiados y solo pueden ser
utilizados por sus destinatarios. Si por error usted recibe este
mensaje, le ofrecemos disculpas, solicitamos eliminarlo de inmediato,
notificarle de su error a la persona que lo envio y abstenerse de
utilizar su contenido.

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message fburgess 2013-05-21 21:53:45 Very slow inner join query Unacceptable latency.
Previous Message Kasahara Tatsuhito 2013-05-21 16:43:11 Re: pg_statsinfo : error could not connect to repository