Re: renice on an I/O bound box
От | Arjen van der Meijden |
---|---|
Тема | Re: renice on an I/O bound box |
Дата | |
Msg-id | 4B561309.60604@tweakers.net обсуждение исходный текст |
Ответ на | renice on an I/O bound box (Willy-Bas Loos <willybas@gmail.com>) |
Ответы |
Re: renice on an I/O bound box
|
Список | pgsql-performance |
On 19-1-2010 13:59 Willy-Bas Loos wrote: > Hi, > > I have a query that runs for about 16 hours, it should run at least weekly. > There are also clients connecting via a website, we don't want to keep > them waiting because of long DSS queries. > > We use Debian Lenny. > I've noticed that renicing the process really lowers the load (in > "top"), though i think we are I/O bound. Does that make any sense? Renicing a postgresql-process can be a very bad thing for the throughput. As it may also possess some locks, which are required by the processes that you think should have a higher priority. Those higher priority processes will be locked by the lower priority one. Then again, renicing postgresql as a whole can be useful. And if your absolutely certain you want to renice a process, renicing a process shouldn't break anything. But it may have some unexpected side effects. Another command to look at, if you're I/O-bound, is the 'ionice' command, which is similar to nice, but obviously intended for I/O. For some I/O-bound background job, one of the 'idle' classes can be a nice level. But for a (single) postgres-process, I'd be careful again for the same reasons as with process-nice. To see which commands do some I/O, looking at 'iotop' may be useful, apart from just examining the output of 'iostat' and similar commands. Best regards, Arjen
В списке pgsql-performance по дате отправления: