Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance

Поиск
Список
Период
Сортировка
Искать
От
Hannu Krosing
Тема
Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance
Дата
Msg-id
52D66FC1.9060809@2ndQuadrant.com
Ответ на
Список
Дерево обсуждения
Linux kernel impact on PostgreSQL performance Mel Gorman <mgorman@suse.de>
Re: Linux kernel impact on PostgreSQL performance (summary v1 2014-1-15) Mel Gorman <mgorman@suse.de>
Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance (summary v2 2014-1-17) Mel Gorman <mgorman@suse.de>
Re: Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance (summary v2 2014-1-17) Andres Freund <andres@2ndquadrant.com>
Re: [Lsf-pc] Re: Linux kernel impact on PostgreSQL performance (summary v2 2014-1-17) Mel Gorman <mgorman@suse.de>
Re: [Lsf-pc] Re: Linux kernel impact on PostgreSQL performance (summary v2 2014-1-17) Andres Freund <andres@2ndquadrant.com>
Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance (summary v2 2014-1-17) Greg Stark <stark@mit.edu>
Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance (summary v2 2014-1-17) Andres Freund <andres@2ndquadrant.com>
Re: Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance (summary v2 2014-1-17) Bruce Momjian <bruce@momjian.us>
Re[2]: [HACKERS] Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance (summary v2 2014-1-17) Миша Тюрин <tmihail@bk.ru>
Re: Re[2]: [HACKERS] Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance (summary v2 2014-1-17) Claudio Freire <klaussfreire@gmail.com>
On 01/15/2014 12:16 PM, Hannu Krosing wrote:
> On 01/14/2014 06:12 PM, Robert Haas wrote:
>> This would be pretty similar to copy-on-write, except
>> without the copying. It would just be
>> forget-from-the-buffer-pool-on-write. 
> +1
>
> A version of this could probably already be implement using MADV_DONTNEED
> and MADV_WILLNEED
>
> Thet is, just after reading the page in, use MADV_DONTNEED on it. When
> evicting
> a clean page, check that it is still in cache and if it is, then
> MADV_WILLNEED it.
>
> Another nice thing to do would be dynamically adjusting kernel
> dirty_background_ratio
> and other related knobs in real time based on how many buffers are dirty
> inside postgresql.
> Maybe in background writer.
>
> Question to LKM folks - will kernel react well to frequent changes to
> /proc/sys/vm/dirty_*  ?
> How frequent can they be (every few second? every second? 100Hz ?)
One obvious use case of this would be changing dirty_background_bytes
linearly to almost zero during a checkpoint to make final fsync fast.

Cheers

-- 
Hannu Krosing
PostgreSQL Consultant
Performance, Scalability and High Availability
2ndQuadrant Nordic OÜ



В списке pgsql-hackers по дате отправления
От: Hannu Krosing
Дата:
От: Florian Pflug
Дата:
Сообщение: Re: plpgsql.warn_shadow
FAQ