| From: | Kevin Grittner <kgrittn(at)gmail(dot)com> |
|---|---|
| To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: what to revert |
| Date: | 2016-05-10 21:03:43 |
| Message-ID: | CACjxUsN6ANGAUidL6eDQDjWzR=PBuaJc4ULA_2kKm0-WNv-YSw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, May 10, 2016 at 2:41 PM, Kevin Grittner <kgrittn(at)gmail(dot)com> wrote:
Re-reading that thread I was reminded that I had more NUMA problems
when data all landed in one memory node, as can happen with pgbench
-i. Note that at scale 100 and 3000 all data would fit in one NUMA
node, and very likely was all going through one CPU socket. The 2
hour warm-up might have rebalanced that to some degree or other,
but as an alternative to the cpuset and NUMA patch, you could stop
PostgreSQL after the initialize, discard OS cache, and start fresh
before your warm-up. That should accomplish about the same thing
-- to better balance the use of memory across the memory nodes and
CPU sockets.
On most NUMA systems you can use this command to see how much
memory is in use on which nodes:
numactl --hardware
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2016-05-10 21:06:15 | Re: what to revert |
| Previous Message | Bert | 2016-05-10 21:00:27 | Re: asynchronous and vectorized execution |