Re: postgresql latency & bgwriter not doing its job

Поиск
Список
Период
Сортировка
Искать
От
Fabien COELHO
Тема
Re: postgresql latency & bgwriter not doing its job
Дата
Msg-id
alpine.DEB.2.10.1408280811590.28571@sto
Ответ на
Список
Дерево обсуждения
postgresql latency & bgwriter not doing its job Fabien COELHO <coelho@cri.ensmp.fr>
Re: postgresql latency & bgwriter not doing its job Andres Freund <andres@2ndquadrant.com>
Re: postgresql latency & bgwriter not doing its job Fabien COELHO <coelho@cri.ensmp.fr>
Re: postgresql latency & bgwriter not doing its job Andres Freund <andres@2ndquadrant.com>
Re: postgresql latency & bgwriter not doing its job Amit Kapila <amit.kapila16@gmail.com>
Re: postgresql latency & bgwriter not doing its job Fabien COELHO <coelho@cri.ensmp.fr>
Re: postgresql latency & bgwriter not doing its job Amit Kapila <amit.kapila16@gmail.com>
Re: postgresql latency & bgwriter not doing its job Fabien COELHO <coelho@cri.ensmp.fr>
Re: postgresql latency & bgwriter not doing its job Jeff Janes <jeff.janes@gmail.com>
Re: postgresql latency & bgwriter not doing its job Fabien COELHO <coelho@cri.ensmp.fr>
Re: postgresql latency & bgwriter not doing its job Jeff Janes <jeff.janes@gmail.com>
Re: postgresql latency & bgwriter not doing its job Fabien COELHO <coelho@cri.ensmp.fr>
Re: postgresql latency & bgwriter not doing its job Jeff Janes <jeff.janes@gmail.com>
Re: postgresql latency & bgwriter not doing its job Jeff Janes <jeff.janes@gmail.com>
Re: postgresql latency & bgwriter not doing its job Fabien COELHO <fabien.coelho@mines-paristech.fr>
Re: postgresql latency & bgwriter not doing its job Fabien COELHO <coelho@cri.ensmp.fr>

Hello Aidan,

> If all you want is to avoid the write storms when fsyncs start happening on
> slow storage, can you not just adjust the kernel vm.dirty* tunables to
> start making the kernel write out dirty buffers much sooner instead of
> letting them accumulate until fsyncs force them out all at once?

I tried that by setting:  vm.dirty_expire_centisecs = 100  vm.dirty_writeback_centisecs = 100

So it should start writing returned buffers at most 2s after they are 
returned, if I understood the doc correctly, instead of at most 35s.

The result is that with a 5000s 25tps pretty small load (the system can do 
300tps with the default configuration), I lost 2091 (1.7%) of 
transactions, that is they were beyond the 200ms schedule limit. Another 
change is that overall the lost transactions are more spread than without 
this setting, although there still is stretches of unresponsiveness.

So although the situation is significantly better, it is still far from 
good with the much reduced value I tried.

-- 
Fabien.


В списке pgsql-hackers по дате отправления
От: Tom Lane
Дата:
Сообщение: Re: Is this code safe?
От: Michael Paquier
Дата:
FAQ