| От | Tom Lane |
|---|---|
| Тема | Re: Performance of pg_dump on PGSQL 8.0 |
| Дата | |
| Msg-id | 26780.1150300307@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Performance of pg_dump on PGSQL 8.0 ("John E. Vincent" <pgsql-performance@lusis.org>) |
| Список | pgsql-performance |
"John E. Vincent" <pgsql-performance@lusis.org> writes:
> I've watched the backup process and I/O is not a problem. Memory isn't a
> problem either. It seems that we're CPU bound but NOT in I/O wait.
Is it the pg_dump process, or the connected backend, that's chewing the
bulk of the CPU time? (This should be pretty obvious in "top".)
If it's the pg_dump process, the bulk of the CPU time is likely going
into compression --- you might consider backing off the compression
level, perhaps --compress=1 or even 0 if size of the dump file isn't
a big concern.
Another possibility if your LAN is reasonably fast is to run pg_dump on
a different machine, so that you can put two CPUs to work.
regards, tom lane
В списке pgsql-performance по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера