Re: performance database for backup/restore

От: Jeison Bedoya
Тема: Re: performance database for backup/restore
Дата: ,
Msg-id: 519BD32F.8040201@audifarma.com.co
(см: обсуждение, исходный текст)
Ответ на: Re: performance database for backup/restore  (Jeff Janes)
Список: pgsql-performance

Скрыть дерево обсуждения

performance database for backup/restore  (Jeison Bedoya, )
 Re: performance database for backup/restore  (Evgeny Shishkin, )
  Re: performance database for backup/restore  ("", )
 Re: performance database for backup/restore  (Steve Crawford, )
 Re: performance database for backup/restore  (Jeff Janes, )
  Re: performance database for backup/restore  (Jeison Bedoya, )

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 <>
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
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 envia y abstenerse de
utilizar su contenido.

В списке pgsql-performance по дате сообщения:

От: Amit Langote
Дата:
Сообщение: Re: pg_statsinfo : error could not connect to repository
От: Amit Kapila
Дата:
Сообщение: Re: Very slow inner join query Unacceptable latency.