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: (view raw, whole thread or download thread mbox)
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?


In response to


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-2017 The PostgreSQL Global Development Group