Re: Vacuum rate limit in KBps

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: Vacuum rate limit in KBps
Дата
Msg-id 5C4C2A81-9334-4069-A8BD-EA49C464B1B9@nasby.net
обсуждение исходный текст
Ответ на Re: Vacuum rate limit in KBps  (Greg Smith <greg@2ndQuadrant.com>)
Ответы Re: Vacuum rate limit in KBps  (Greg Smith <greg@2ndQuadrant.com>)
Список pgsql-hackers
On Jan 15, 2012, at 8:13 PM, Greg Smith wrote:
> On 01/15/2012 04:17 PM, Heikki Linnakangas wrote:
>> I think it makes more sense to use the max read rate as the main knob, rather than write rate. That's because the
maxread rate is higher than the write rate, when you don't need to dirty pages. Or do you think saturating the I/O
systemwith writes is so much bigger a problem than read I/O that it makes more sense to emphasize the writes? 
>
> I haven't had the I/O rate logging available for long enough to have a good feel for which is more important to
emphasize. I'm agnostic on this.  I'd have no problem accepting the argument that exposing the larger of the two
rates--whichis the read one--makes for a cleaner UI.  Or that it is the one more like other knobs setting precedents
here.

Could we expose both?

On our systems writes are extremely cheap... we don't do a ton of them (relatively speaking), so they tend to just fit
intoBBU cache. Reads on the other hard are a lot more expensive, at least if they end up actually hitting disk. So we
actuallyset page_dirty and page_hit the same. 
--
Jim C. Nasby, Database Architect                   jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net




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

Предыдущее
От: Fujii Masao
Дата:
Сообщение: Re: Patch review for logging hooks (CF 2012-01)
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: automating CF submissions (was xlog location arithmetic)