Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Vu2g0-0004PQ-SB for pgsql-performance@arkaria.postgresql.org; Fri, 20 Dec 2013 16:11:49 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Vu2g0-0007vs-C9 for pgsql-performance@arkaria.postgresql.org; Fri, 20 Dec 2013 16:11:48 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Vu2fz-0007vl-5X for pgsql-performance@postgresql.org; Fri, 20 Dec 2013 16:11:47 +0000 Received: from smtp.peak6.com ([38.98.137.6]) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Vu2fv-0004MR-0J for pgsql-performance@postgresql.org; Fri, 20 Dec 2013 16:11:46 +0000 X-AuditID: 0a64cb20-b7f256d000000fb3-ff-52b46c3c46bf Message-ID: <52B46C3B.20902@optionshouse.com> Date: Fri, 20 Dec 2013 10:11:39 -0600 From: Shaun Thomas User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Sev Zaslavsky , Sergey Konoplev CC: "pgsql-performance@postgresql.org" Subject: Re: slow query - will CLUSTER help? References: <52A9F2A2.4080901@gmail.com> <52B35CF9.9080402@gmail.com> <52B4574E.7040800@optionshouse.com> <52B468E9.8030902@gmail.com> In-Reply-To: <52B468E9.8030902@gmail.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+NgFnrEIsWRmVeSWpSXmKPExsXClcIroWuTsyXIoH+qosWRxXoW12eeY7aY 2PyO2YHZY+esu+weF/ZNYw9gimpgtEnMy8svSSxJVUhJLU62VfIvKMnMzyv2yC8tTlVwySxO zknMzE0tUlLITLFVMlZSKMhJTE7NTc0rsVVKLChIzUtRsuNSwAA2QGWZeQqpecn5KZl56bZK nsH+uhYWppa6hkp28cggoZMlY9mJr0wFN7grji7azdTAOJezi5GTQ0LAROLP5qWMELaYxIV7 69lAbF4BXYl9uy+xdjFycLAIqEpsfakKEmYDCk/qXwFWIioQJtF+YSYzRLmgxMmZT1hAbBEB T4k502+D2cxAdsepVWDjhQXMJLasnMrexcjFISQwgUli4Ye3YM2cApoSV18dg2qwlbgw5zqU LS+x/e0csBohoBtWNE9kg7hTQeL/lXdMExgFZiHZPQtJ+ywk7QsYmVcxiheXJSZnZJoWFOeW FBjpFaQmZpvp5aWWbGIER+RphR2M3zutDjEKcDAq8fA2Zm4JEmJNLCuuzD3EKMHBrCTCuxkk xJuSWFmVWpQfX1Sak1p8iNEHGDYTmaVEk/OBySKvJN7Q2NTA1NLU0NTc1NAIh7CSOC9XztQg IYF0YGrITk0tSC2CGcfEwSnVwHhCeOocGaFrxzeGLP+14nbWxPZP5t/lJjitfFfkfj/h653N Dt8uanLsk5hwodNx2/lDsb9/ei/eJ9m0KvCfJNdVP8H1pnXlSQ+vsz95Xu+c/brHs/yV1SeX xLS33eGXGLqNlor/lEus+ZA95V/nSVHlT/cEzMr1Dluc1ZvoXb3/qwpn/hqP/3uVWIozEg21 mIuKEwEW6hA/9QIAAA== X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org On 12/20/2013 09:57 AM, Sev Zaslavsky wrote: > There is a separate RAID-1 for WAL, another for tablespace and another > for operating system. I tend to stick to DB-size / 10 as a minimum, but I also have an OLTP system. For a more OLAP-type, the ratio is negotiable. The easiest way to tell is to monitor your disk IO stats. If you're seeing a READ-based utilization percentage over 50% consistently, you need more RAM. On our system, we average 10% through the day except for maintenance and loading phases. Of course, that's only for the current DB size. A good trick is to monitor your DB size changes on a daily basis, plot the growth percentage for a week, and apply compounding growth to estimate the size in three years. Most companies I've seen are on a 3-year replacement cycle, so that gives you how much you'll have to buy in order to avoid another spend until the next iteration. For example, say you have a 800GB database, and it grows at 10GB per week, so that's 40GB per month. In three years, you could need up to: 800 * (1 + 40/800)^36 = 4632GB of space, which translates to roughly 480-512 GB of RAM. You can probably find a comfortable middle ground with 240GB. Of course, don't forget to buy modules in multiples of four, otherwise you're not taking advantage of all the CPU's memory channels. :) -- Shaun Thomas OptionsHouse | 141 W. Jackson Blvd. | Suite 500 | Chicago IL, 60604 312-676-8870 sthomas@optionshouse.com ______________________________________________ See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance