Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TQMgX-0005ZS-Vz for pgsql-performance@postgresql.org; Mon, 22 Oct 2012 18:25:10 +0000 Received: from smtp2.peak6.com ([38.98.137.9]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TQMgR-0005Lu-2E for pgsql-performance@postgresql.org; Mon, 22 Oct 2012 18:25:09 +0000 X-AuditID: 0a02cb20-b7f726d000005255-06-50858f7c08dc Received: from sswchi5pcas2.peak6.net (sswchi5pcas2.peak6.net [10.100.13.24]) by smtp2.peak6.com (Symantec Messaging Gateway) with SMTP id 1C.02.21077.C7F85805; Mon, 22 Oct 2012 13:25:00 -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:25:00 -0500 Message-ID: <50858F7B.4040802@optionshouse.com> Date: Mon, 22 Oct 2012 13:24:59 -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: "Franklin, Dan (FEN)" CC: Claudio Freire , 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> <5C92D015D36C6248AFA3806E72C04A06067B7320@usoldt-e3mb-008.PEROOT.COM> In-Reply-To: <5C92D015D36C6248AFA3806E72C04A06067B7320@usoldt-e3mb-008.PEROOT.COM> 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+NgFprFKsWRmVeSWpSXmKPExsXClcIroVvT3xpgcO+5kcWUdTdYLJ78amK1 uD7zHLMDs8fOWXfZPW4c28nqcWHfNPYA5qgGRpvEvLz8ksSSVIWU1OJkWyX/gpLM/Lxij/zS 4lQFl8zi5JzEzNzUIiWFzBRbJWMlhYKcxOTU3NS8ElulxIKC1LwUJTsuBQxgA1SWmaeQmpec n5KZl26r5Bnsr2thYWqpa6hkF48MEjpZMnatuMdWcJG1Yu7EbWwNjKdYuhg5OSQETCT2dSxm hbDFJC7cW8/WxcjFISRwglHixJXPLBDOSkaJW28fMIJU8QroS2zumgjWwSKgKtHwcxM7iM0m oCsxqX8FG4gtJKAi0Xf2BhOIzS8gLLHvQxMziC0qECaxfOdmJog5ghInZz4Bu0IE6IrrL+6C zWQWCJTonvwQLC4sYC/R9f8BM8TMLmaJ/cfLQWxOgSCJaZu+Q9XbSlyYc50FwpaX2P52DlS9 qsSK5olsEJ8pSPy/8o5pAqPILCSrZyFpn4WkfQEj8ypG8eKyxOSMTLOC4tySAiO9gtTEbDO9 vNSSTYygBMB0WmEH4+Yeq0OMAhyMSjy8H961BAixJpYVV+YeYpTgYFYS4VUOaA0Q4k1JrKxK LcqPLyrNSS0+xOgDDLOJzFKiyfnA5JRXEm9obGpgamlqaGpuamiEQ1hJnHfStsYAIYF0YPrJ Tk0tSC2CGcfEwSnVwKgimbry2nR/vfjX2XcdrqxfMNejaIbrMZMiK95TrhlKDBOOLZY6utJ5 SzCnRr2vMZOYgGlJWMNpjRqPRS7hXs6tztKB3XwhB8ROXfOZpdJ+ojl9/YaLvHxL7HkaF2do Xili1g+5v8zyy7YFH02PWzGVTd7nK11wt3SDBQvjS48qpxytRdNuKbEUZyQaajEXFScCAOVC 4bctAwAA X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201210/289 X-Sequence-Number: 48248 On 10/22/2012 01:20 PM, Franklin, Dan (FEN) wrote: > http://blog.jcole.us/2010/09/28/mysql-swap-insanity-and-the-numa-archite > cture/ Yeah, I remember reading that a while back. While interesting, it doesn't really apply to PG, in that unlike MySQL, we don't allocate any large memory segments directly to any large block. With MySQL, it's not uncommon to dedicate over 50% of RAM to the MySQL process itself, but I don't often see PG systems with more than 8GB in shared_buffers. All the rest should be available for random allocation in general. At least, in theory. -- 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