Re: Noticed something odd with pgbench
От | Shaun Thomas |
---|---|
Тема | Re: Noticed something odd with pgbench |
Дата | |
Msg-id | 50A69D61.8070302@optionshouse.com обсуждение исходный текст |
Ответ на | Re: Noticed something odd with pgbench (Richard Huxton <dev@archonet.com>) |
Список | pgsql-general |
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 sthomas@optionshouse.com ______________________________________________ See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email
В списке pgsql-general по дате отправления: