Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance
От
Dave Chinner
Тема
Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance
Дата
Msg-id
20140115022556.GS3469@dastard
Ответ на
Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance (Jonathan Corbet)
Список
Дерево обсуждения
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 Tue, Jan 14, 2014 at 05:38:10PM -0700, Jonathan Corbet wrote: > On Wed, 15 Jan 2014 09:23:52 +1100 > Dave Chinner wrote: > > > It appears to me that we are seeing large memory machines much more > > commonly in data centers - a couple of years ago 256GB RAM was only > > seen in supercomputers. Hence machines of this size are moving from > > "tweaking settings for supercomputers is OK" class to "tweaking > > settings for enterprise servers is not OK".... > > > > Perhaps what we need to do is deprecate dirty_ratio and > > dirty_background_ratio as the default values as move to the byte > > based values as the defaults and cap them appropriately. e.g. > > 10/20% of RAM for small machines down to a couple of GB for large > > machines.... > > I had thought that was already in the works...it hits people on far > smaller systems than those described here. > > http://lwn.net/Articles/572911/ > > I wonder if anybody ever finished this work out for 3.14? Not that I know of. This patch was suggested as the solution to the slow/fast drive issue that started the whole thread: http://thread.gmane.org/gmane.linux.kernel/1584789/focus=1587059 but I don't see it in a current kernel. It might be in Andrew's tree for 3.14, but I haven't checked. However, most of the discussion in that thread about dirty limits was a side show that rehashed old territory. Rate limiting and throttling in a generic, scalable manner is a complex problem. We've got some of the infrastructure we need to solve the problem, but there was no conclusion as to the correct way to connect all the dots. Perhaps it's another topic for the LSFMM conf? Cheers, Dave. -- Dave Chinner david@fromorbit.com
В списке pgsql-hackers по дате отправления