pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Shaun Thomas <sthomas@optionshouse.com>
To: Sev Zaslavsky <sevzas@gmail.com>
To: Sergey Konoplev <gray.ru@gmail.com>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Subject: Re: slow query - will CLUSTER help?
Date: Fri, 20 Dec 2013 10:11:39 -0600
Message-ID: <52B46C3B.20902@optionshouse.com> (raw)
In-Reply-To: <52B468E9.8030902@gmail.com>
References: <52A9F2A2.4080901@gmail.com>
	<CAL_0b1ty0gS+XP9L=v+jsAT8KXMY5yAW2P0f2fjjjncdYLU3WA@mail.gmail.com>
	<52B35CF9.9080402@gmail.com>
	<CAL_0b1vGV0kWyVKJM=kOYonEXyt1O0a44STbDpknJKhbFyw_XQ@mail.gmail.com>
	<52B4574E.7040800@optionshouse.com>
	<52B468E9.8030902@gmail.com>
List-Unsubscribe:  <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>

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



view thread (10+ messages)  latest in thread

Message-ID: <52B46C3B.20902@optionshouse.com>
Permalink:  ../52B46C3B.20902@optionshouse.com/
Also on:    postgresql.org/message-id/52B46C3B.20902@optionshouse.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: sthomas@optionshouse.com, sevzas@gmail.com, gray.ru@gmail.com
  Subject: Re: slow query - will CLUSTER help?
  In-Reply-To: <52B46C3B.20902@optionshouse.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox