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 <jeff.janes@gmail.com>) |
Список | 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
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@audifarma.com.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
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 по дате отправления:
Предыдущее
От: Kasahara TatsuhitoДата:
Сообщение: Re: pg_statsinfo : error could not connect to repository