Greg Smith <greg@2ndQuadrant.com> wrote:
> You can tell if this is turned on like this:
>
> echo /proc/sys/vm/zone_reclaim_mode
As a data point, the benchmarks I did for some of the 9.2
scalability features does not appear to have this turned on:
# cat /proc/sys/vm/zone_reclaim_mode
0
Our Linux version:
Linux version 2.6.32.46-0.3-default (geeko@buildhost) (gcc version
4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux) ) #1 SMP
2011-09-29 17:49:31 +0200
This has 32 cores (64 "threads" with HT) on 4 Xeon X7560 CPUs.
Intel(R) Xeon(R) CPU X7560 @ 2.27GHz
It has 256GB RAM on 4GB DIMMs, with each core controlling 2 DIMMs
and each core able to directly talk to every other core. So, it
is non-uniform, but with this arrangement it is more a matter that
there is an 8GB set of memory that is "fast" for each core and the
other 97% of RAM is all accessible at the same speed. There were
some other options for what to install on this system or how to
install it which wouldn't have kept things this tight.
> Install the numactl utility and you can see why it's made that
> decision:
We get this:
# numactl --hardware
available: 4 nodes (0-3)
node 0 cpus: 0 1 2 3 4 5 6 7 32 33 34 35 36 37 38 39
node 0 size: 65519 MB
node 0 free: 283 MB
node 1 cpus: 8 9 10 11 12 13 14 15 40 41 42 43 44 45 46 47
node 1 size: 65536 MB
node 1 free: 25 MB
node 2 cpus: 16 17 18 19 20 21 22 23 48 49 50 51 52 53 54 55
node 2 size: 65536 MB
node 2 free: 26 MB
node 3 cpus: 24 25 26 27 28 29 30 31 56 57 58 59 60 61 62 63
node 3 size: 65536 MB
node 3 free: 25 MB
node distances:
node 0 1 2 3
0: 10 11 11 11
1: 11 10 11 11
2: 11 11 10 11
3: 11 11 11 10
When considering a hardware purchase, it might be wise to pay close
attention to how "far" a core may need to go to get to the most
"distant" RAM.
-Kevin
