Re: speed up restore from dump

Поиск
Список
Период
Сортировка
От Sam Mason
Тема Re: speed up restore from dump
Дата
Msg-id 20081031120708.GE2459@frubble.xen.chris-lamb.co.uk
обсуждение исходный текст
Ответ на Re: speed up restore from dump  (Alan Hodgson <ahodgson@simkin.ca>)
Ответы Re: speed up restore from dump  (Robert Treat <xzilla@users.sourceforge.net>)
Список pgsql-general
On Thu, Oct 30, 2008 at 02:28:38PM -0700, Alan Hodgson wrote:
> On Thursday 30 October 2008, Joao Ferreira <jmcferreira@critical-links.com>
> wrote:
> > well..... see for yourself... (360 RAM , 524 SWAP) that's what it is...
> > it supposed to be somewhat an embedded product...
>
> Clearly your hardware is your speed limitation. If you're swapping at all,
> anything running on the machine is going to be slow.

The vmstat output only showed the odd block going in and out; but
performance is only really going to suffer when it's thrashing.  If the
swap in number stays in the double digits for a reasonable amount of
time then you should probably look at what's causing it.  Giving memory
back to the system to use for caching the file system can be good, lots
of shared memory can also be good.

Building indexes takes time and IO bandwidth, maybe you could look at
building less of them?  I'd be tempted to pull the import script apart
into its constituent parts, i.e. the initial data load, and then all the
constraints/index builds separately.  Then run through executing them by
hand and see what you can change to make things more efficient.


   Sam

В списке pgsql-general по дате отправления:

Предыдущее
От: Sam Mason
Дата:
Сообщение: Re: a LEFT JOIN problem
Следующее
От: Sam Mason
Дата:
Сообщение: Re: Storage location of temporary files