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

Re: Tuning Tips for a new Server

From: Andy Colson <andy(at)squeakycode(dot)net>
To: Ogden <lists(at)darkstatic(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Tuning Tips for a new Server
Date: 2011-08-17 13:41:46
Message-ID: 4E4BC51A.2080503@squeakycode.net (view raw or flat)
Thread:
Lists: pgsql-performance
On 8/16/2011 8:35 PM, Ogden wrote:
> Hope all is well. I have received tremendous help from this list prior and therefore wanted some more advice.
>
> I bought some new servers and instead of RAID 5 (which I think greatly hindered our writing performance), I configured 6 SCSI 15K drives with RAID 10. This is dedicated to /var/lib/pgsql. The main OS has 2 SCSI 15K drives on a different virtual disk and also Raid 10, a total of 146Gb. I was thinking of putting Postgres' xlog directory on the OS virtual drive. Does this even make sense to do?
>
> The system memory is 64GB and the CPUs are dual Intel E5645 chips (they are 6-core each).
>
> It is a dedicated PostgreSQL box and needs to support heavy read and moderately heavy writes.
>
> Currently, I have this for the current system which as 16Gb Ram:
>
>   max_connections = 350
>
> work_mem = 32MB
> maintenance_work_mem = 512MB
> wal_buffers = 640kB
>
> # This is what I was helped with before and made reporting queries blaze by
> seq_page_cost = 1.0
> random_page_cost = 3.0
> cpu_tuple_cost = 0.5
> effective_cache_size = 8192MB
>
> Any help and input is greatly appreciated.
>
> Thank you
>
> Ogden

What seems to be the problem?  I mean, if nothing is broke, then don't 
fix it :-)

You say reporting query's are fast, and the disk's should take care of 
your slow write problem from before.  (Did you test the write 
performance?)  So, whats wrong?


-Andy

In response to

Responses

pgsql-performance by date

Next:From: OgdenDate: 2011-08-17 14:28:56
Subject: Re: Tuning Tips for a new Server
Previous:From: Eyal WildeDate: 2011-08-17 06:49:05
Subject: Re: index not being used when variable is sent

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