Re: pg_dump & performance degradation

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_dump & performance degradation
Дата
Msg-id 9479.964884845@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg_dump & performance degradation  (Philip Warner <pjw@rhyme.com.au>)
Ответы Re: pg_dump & performance degradation
Re: pg_dump & performance degradation
Список pgsql-hackers
Philip Warner <pjw@rhyme.com.au> writes:
>> "nice" doesn't help at all when you try it?

> Only marginally; and what I really need to do is 'nice' the backend, and
> when I do that it still only helps only a little - even if I drop it to the
> lowest priority. I think a process with only a little CPU can still do a
> lot of I/O requests, and perhaps it is getting swapped back in to service
> the requests. This is just guesswork.

I think that's true --- on most Unixes, 'nice' level only affects CPU
scheduling not I/O scheduling.

It would be a bad idea to nice down a backend anyway, if the intent is
to speed up other backends.  The Unix scheduler has no idea about
application-level locking, so you'll get priority-inversion problems:
once the nice'd backend has acquired any sort of lock, other backends
that may be waiting for that lock are at the mercy of the low priority
setting.  In effect, your entire database setup may be running at the
nice'd priority relative to anything else on the system.

I think Philip's idea of adding some delays into pg_dump is a reasonable
answer.  I'm just recommending a KISS approach to implementing the
delay, in the absence of evidence that a more complex mechanism will
actually buy anything...
        regards, tom lane


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

Предыдущее
От: "Hiroshi Inoue"
Дата:
Сообщение: RE: bufmgr and smgr don't talk to each other, apparently
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Inprise InterBase(R) 6.0 Now Free and Open Source