Received: from makus.postgresql.org ([98.129.198.125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TQMjg-0007BH-NY for pgsql-performance@postgresql.org; Mon, 22 Oct 2012 18:28:24 +0000 Received: from smtp2.peak6.com ([38.98.137.9]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TQMjd-0003rW-Qc for pgsql-performance@postgresql.org; Mon, 22 Oct 2012 18:28:23 +0000 X-AuditID: 0a02cb20-b7f726d000005255-42-50859044ecd2 Received: from sswchi5pcas2.peak6.net (sswchi5pcas2.peak6.net [10.100.13.24]) by smtp2.peak6.com (Symantec Messaging Gateway) with SMTP id AE.02.21077.44095805; Mon, 22 Oct 2012 13:28:20 -0500 (CDT) Received: from [10.10.201.64] (10.10.201.64) by sswchi5pcas2.peak6.net (10.100.13.25) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 22 Oct 2012 13:28:20 -0500 Message-ID: <50859043.7020603@optionshouse.com> Date: Mon, 22 Oct 2012 13:28:19 -0500 From: Shaun Thomas Reply-To: Organization: Peak6 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: Claudio Freire CC: "pgsql-performance@postgresql.org" Subject: Re: Tons of free RAM. Can't make it go away. References: <508583E4.8080102@optionshouse.com> <5085873D.60400@optionshouse.com> <508589F8.7020808@optionshouse.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed content-transfer-encoding: 7bit X-Originating-IP: [10.10.201.64] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAKsWRmVeSWpSXmKPExsXClcIroesyoTXAYGWLlcWTX02sFtdnnmN2 YPLYOesuu8eFfdPYA5iiGhhtEvPy8ksSS1IVUlKLk22V/AtKMvPzij3yS4tTFVwyi5NzEjNz U4uUFDJTbJWMlRQKchKTU3NT80pslRILClLzUpTsuBQwgA1QWWaeQmpecn5KZl66rZJnsL+u hYWppa6hkl08MkjoZMk4cHEnc0EvW0Xbpn/sDYxvWLoYOTgkBEwkvpxO6WLkBDLFJC7cW8/W xcjFISRwglHiZ/9VKGclo8TtzY+ZQKp4BfQlLn//CGazCKhKvJ75hxHEZhPQlZjUv4INxBYS UJHoO3sDrIZfQFhi34cmZhBbVCBMYvnOzVBzBCVOznzCAmKLCGhLnLm7iR3EZhbwlOg4tQps prCAvUTX/wfMEEccYZL4dbsNbAGnQKDE/fatTBANthIX5lxngbDlJba/ncMMcYSqxIrmiWwQ rylI/L/yjmkCo8gsJLtnIWmfhaR9ASPzKkbx4rLE5IxMs4Li3JICI72C1MRsM7281JJNjKBo ZzqtsINxc4/VIUYBDkYlHt4P71oChFgTy4orcw8xSnAwK4nwKge0BgjxpiRWVqUW5ccXleak Fh9i9AEG2kRmKdHkfGAiyiuJNzQ2NTC1NDU0NTc1NMIhrCTOO2lbY4CQQDow/WSnphakFsGM Y+LglGpgXHths8F0dcYTGcv472+Zu/j7l8+bhUK2m654EPbnREbjki3qHY+774cFa7wRsPjR df7J/e1fD5+/t3He7bKbFX+PC+RcZS5jWvfBx+XTlD5Dt6XxK/17ZX0V3BdJ3p21b9cJlwkX q1WeT0tkmjqVbYmkuNoNoZfX7gnVnJ+V/CRoLuuSqAe+q4yVWIozEg21mIuKEwGmZQTMIwMA AA== X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201210/290 X-Sequence-Number: 48249 On 10/22/2012 01:14 PM, Claudio Freire wrote: > You may want to try setting the numa policy before launching postgres: > > numactl --interleave=all pg_ctl start I thought about that. I'd try it on one of our stage nodes, but both of them show an even memory split. I'm not sure why our prod node is acting this way. We've used bcfg2 so every server has the exact same configuration, including kernel parameters, startup settings, and so on. I can only conclude that there's something about the activity itself that's causing it. I'll have to take another look after the market closes to see if the unallocated chunk shrinks. -- 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