Skip site navigation (1) Skip section navigation (2)

Re: tune memory usage for master/slave nodes in cluster

From: Greg Smith <greg(at)2ndquadrant(dot)com>
To: stanimir petrov <cristal_reaver(at)abv(dot)bg>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: tune memory usage for master/slave nodes in cluster
Date: 2010-07-21 15:08:36
Message-ID: 4C470D74.8010509@2ndquadrant.com (view raw or flat)
Thread:
Lists: pgsql-performance
stanimir petrov wrote:
> Now the servers are dual core CPU 2.6 with 1.7 GB RAM and i standart 
> disk. (the small instance from AWS)

You're never going to be able to tune for writing data fast on a AWS 
environment; there just isn't enough disk throughput available.  If this 
application really does take off the way you expect it to, don't be 
surprised to find you have to move it to real hardware to keep up.  
Dedicated database servers tend to have tens of disks in them to keep up 
with the sort of load you're expecting, and you just can't get that in a 
cloud environment.  You can do some work to improve I/O using multiple 
storage instances; 
http://blog.endpoint.com/2010/02/postgresql-ec2-ebs-raid0-snapshot.html 
is a good introduction to that.

The basic tuning advice you're looking for is available at 
http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server

If you are trying to get faster writes out of AWS hardware, you may have 
to turn off synchronous_commit to accomplish that.  That has some 
potential lost transaction downsides, but simple disks just can't write 
data that fast so it may be the only way to make this work well.

-- 
Greg Smith  2ndQuadrant US  Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com   www.2ndQuadrant.us


In response to

pgsql-performance by date

Next:From: Kneringer, ArminDate: 2010-07-21 16:47:54
Subject: Re: potential performance gain by query planner optimization
Previous:From: Greg SmithDate: 2010-07-21 14:59:53
Subject: Re: Using more tha one index per table

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group