From: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Merlin Moncure <mmoncure(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: NUMA packaging and patch |
Date: | 2014-06-09 17:00:08 |
Message-ID: | 1402333208.50953.YahooMailNeo@web122302.mail.ne1.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> On 2014-06-09 08:59:03 -0700, Kevin Grittner wrote:
>>> *) There is a lot of advice floating around (for example here:
>>> http://frosty-postgres.blogspot.com/2012/08/postgresql-numa-and-zone-reclaim-mode.html )
>>> to instruct operators to disable zone_reclaim. Will your changes
>>> invalidate any of that advice?
>>
>> I expect that it will make the need for that far less acute,
>> although it is probably still best to disable zone_reclaim (based
>> on the documented conditions under which disabling it makes sense).
>
> I think it'll still be important unless you're running an OLTP workload
> (i.e. minimal per backend allocations) and your entire workload fits
> into shared buffers. What zone_reclaim > 0 essentially does is to never
> allocate memory from remote nodes. I.e. it will throw away all numa node
> local OS cache to satisfy a memory allocation (including
> pagefaults).
I don't think that cpuset spreading of OS buffers and cache, and
the patch to spread shared memory, will make too much difference
unless the working set is fully cached. Where I have seen the
biggest problems is when the active set > one memory node and <
total machine RAM. I would agree that unless this patch is
providing benefit for such a fully-cached load, it won't make any
difference regarding the need for zone_reclaim_mode. Where the
data is heavily cached, zone_reclaim > 0 might discard some cached
pages to allow, say, a RAM sort to be done in faster memory (for
the current process's core), so it might be a wash or even make
zone_reclaim > 0 a win.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-06-09 17:03:13 | Re: Inaccuracy in VACUUM's tuple count estimates |
Previous Message | Claudio Freire | 2014-06-09 16:58:53 | Re: Extended Prefetching using Asynchronous IO - proposal and patch |