Received: from makus.postgresql.org ([98.129.198.125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TSs1f-0002tq-Ny for pgsql-performance@postgresql.org; Mon, 29 Oct 2012 16:17:19 +0000 Received: from smtp.peak6.com ([38.98.137.6]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TSs1e-0001uJ-1x for pgsql-performance@postgresql.org; Mon, 29 Oct 2012 16:17:19 +0000 X-AuditID: 0a64cb20-b7f6b6d000003c0d-e4-508eac0cbe8e Message-ID: <508EAC0B.7010609@optionshouse.com> Date: Mon, 29 Oct 2012 11:17:15 -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: =?UTF-8?B?0JLRltGC0LDQu9GW0Lkg0KLQuNC80YfQuNGI0LjQvQ==?= CC: "pgsql-performance@postgresql.org" Subject: Re: Tons of free RAM. Can't make it go away. References: <508583E4.8080102@optionshouse.com> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Length: 1530 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.10.201.64] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKIsWRmVeSWpSXmKPExsXClcIrocu7pi/AYGc7m8X1meeYLdaffMvm wOSxc9Zddo8L+6axBzBFNTDaJObl5ZcklqQqpKQWJ9sq+ReUZObnFXvklxanKrhkFifnJGbm phYpKWSm2CoZKykU5CQmp+am5pXYKiUWFKTmpSjZcSlgABugssw8hdS85PyUzLx0WyXPYH9d CwtTS11DJbt4ZJDQyZLxa3krU8EaroreY81sDYyzOboYOTkkBEwkGvu3sEDYYhIX7q1nA7F5 BfQlznz/zwhiswioSjx9MA8sziagKzGpfwWYLSSgItF39gYTiM0vICyx70MTM4gtKhAmsXzn ZiaIOYISJ2c+AZsvIhAoMe/jE7AaZgFPiY5Tq8DmCwvYS3T9f8AMMbNE4vOPbqD5HBycQPWL vsRClFtILH5zkB3Clpdo3jobqlxVYkXzRDaI8xUk/l95xzSBUWgWks2zkLTPQtK+gJF5FaN4 cVlickamaUFxbkmBkV5BamK2mV5easkmRnDcnlbYwfi90+oQowAHoxIPr8HH3gAh1sSy4src Q4wSHMxKIry/ZvUFCPGmJFZWpRblxxeV5qQWH2L0AQbZRGYp0eR8YErJK4k3NDY1MLU0NTQ1 NzU0wiGsJM576XZbgJBAOjCRZKemFqQWwYxj4uCUamAUT/f8mnKq5cjb1y4r1CcuKcwvvpVt 9H3hGsnUbXJu6g7TGOttpjttK7dgn3n7bfdOecOyuesPTX59Odc+Ynab7NKZrMUie6IXva0S Z+HzPSLyutP81opb6x6Uv/2yPyySbS3rzIn5bVedl1p4LHzh4sD7mrN74WSrV2lL3bufNnV8 KJ5Rc89YiaU4I9FQi7moOBEAJ5LPRAgDAAA= X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201210/350 X-Sequence-Number: 48309 On 10/27/2012 10:49 PM, =D0=92=D1=96=D1=82=D0=B0=D0=BB=D1=96=D0=B9 =D0=A2=D0=B8=D0=BC=D1=87=D0=B8=D1=88=D0=B8=D0=BD wrote: > It can be that some query(s) use a lot of work mem, either because of > high work_mem setting or because of planner error. In this case the > moment query runs it will need memory that will later be returned and > become free. Usually this can be seen as active memory spike with a lot > of free memory after. Yeah, I had briefly considered that. But our work-mem is only 16MB, and even a giant query would have trouble allocating 10+GB with that size of work-mem buckets. That's why I later listed the numa info. In our case, processor 0 is heavily unbalanced with its memory accesses compared to processor 1. I think the theory that we didn't start with interleave put an 8GB (our shared_buffers) segment all on processor 0, which unbalanced a lot of other stuff. Of course, that leaves 4-6GB unaccounted for. And numactl still shows a heavy preference for freeing memory from proc 0. It seems to only do it on this node, so we're going to switch nodes soon and see if the problem reappears. We may have to perform a node hardware audit if this persists. Thanks for your input, though. :) -- 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