Re: [PATCHES] Load distributed checkpoint patch

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: [PATCHES] Load distributed checkpoint patch
Дата
Msg-id 458ADB87.EE98.0025.0@wicourts.gov
обсуждение исходный текст
Ответ на Re: [PATCHES] Load distributed checkpoint patch  ("Takayuki Tsunakawa" <tsunakawa.takay@jp.fujitsu.com>)
Ответы Re: [PATCHES] Load distributed checkpoint patch  (ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>)
Список pgsql-hackers
>>> On Wed, Dec 20, 2006 at  6:05 AM, in message
<03be01c7242f$2b4ce130$19527c0a@OPERAO>, "Takayuki Tsunakawa"
<tsunakawa.takay@jp.fujitsu.com> wrote: 
> 
> I consider that smoothing the load (more meaningfully, response
time)
> has higher priority over checkpoint punctuality in a practical
sense,
> because the users of a system benefit from good steady response and
> give good reputation to the system.
I agree with that.
> If the checkpoint processing is
> not punctual, crash recovery would take longer time.  But which
would
> you give higher priority, the unlikely event (=crash of the system)
or
> likely event (=peek hours of the system)?  I believe the latter
should
> be regarded.
I'm still with you here.
> The system can write dirty buffers after the peek hours
> pass.
I don't see that in our busiest environment.
We have 3,000 "directly connected" users, various business partner
interfaces, and public web entry doing OLTP in 72 databases distributed
around the state, with real-time replication to central databases which
are considered derived copies.  If all the pages modified on the central
databases were held in buffers or cache until after peak hours, query
performance would suffer -- assuming it would all even fit in cache.  We
must have a way for dirty pages to be written under load while
responding to hundreds of thousands of queries per hour without
disturbing "freezes" during checkpoints.
On top of that, we monitor database requests on the source machines,
and during "idle time" we synchronize the data with all of the targets
to identify, log, and correct "drift".  So even if we could shift all
our disk writes to the end of the day, that would have its own down
side, in extending our synchronization cycle.
I raise this only to be sure that such environments are considered with
these changes, not to discourage improvements in the checkpoint
techniques.  We have effectively eliminated checkpoint problems in our
environment with a combination of battery backed controller cache and
aggressive background writer configuration.  When you have a patch which
seems to help those who still have problems, I'll try to get time
approved to run a transaction replication stream onto one of our servers
(in "catch up mode") while we do a web "stress test" by playing back
requests from our production log.  That should indicate how the patch
will affect us.
-Kevin



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

Предыдущее
От: "Kevin Grittner"
Дата:
Сообщение: Re: Companies Contributing to Open Source
Следующее
От: Gregory Stark
Дата:
Сообщение: Re: column ordering, was Re: [PATCHES] Enums patch v2