On 11/16/2012 01:59 PM, Richard Huxton wrote:
http://frosty-postgres.blogspot.co.uk/2012/08/postgresql-numa-and-zone-reclaim-mode.html
I actually considered zone_reclaim_mode. But the article you linked to
misses a point: during boot, zone_reclaim_mode is chosen only if the
zone distance is > 20, otherwise it's disabled. And in our case:
#> cat /proc/sys/vm/zone_reclaim_mode
0
#> numactl --hardware
available: 2 nodes (0-1)
node 0 cpus: 0 2 4 6 8 10 12 14 16 18 20 22
node 0 size: 36853 MB
node 0 free: 6456 MB
node 1 cpus: 1 3 5 7 9 11 13 15 17 19 21 23
node 1 size: 36863 MB
node 1 free: 6921 MB
node distances:
node 0 1
0: 10 20
1: 20 10
I actually hoped that was the problem, but no such luck. Now... there is
the possibility that the 3.2 kernel variant we're using has some bug
where it's not honoring this setting, but evidence suggests it's
something else.
What's annoying about the above numactl output is that the OS is
ignoring 12GB of RAM, while still marking 15GB of cache as inactive. So
we're really getting 27GB less cache than usual. It's pretty obvious
when watching system load.
I'm getting ready to start grabbing mainline kernels and compiling them
to try and track this down.
--
Shaun Thomas
OptionsHouse | 141 W. Jackson Blvd. | Suite 500 | Chicago IL, 60604
312-444-8534
stho...@optionshouse.com
______________________________________________
See http://www.peak6.com/email_disclaimer/ for terms and conditions related to
this email
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
