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

Re: SAN performance

From: Mr Pink <mr_pink_is_the_only_pro(at)yahoo(dot)com>
To: Anjan Dave <adave(at)vantage(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: SAN performance
Date: 2004-09-23 15:39:31
Message-ID: 20040923153931.34861.qmail@web41110.mail.yahoo.com (view raw or flat)
Thread:
Lists: pgsql-performance
Hi,

I expect you mean RAID 1/0 or 1+0 since the CX300 didn't support RAID 10 last time I looked.

Whether you are using a SAN or not, you should consider putting the WAL files (pg_xlog folder) on
seperate diskes from the DB. Since the log files are mostly written to, not read from you could
just use RAID 1. 

It's a pity pg doesn't have a way to use a cluster of servers to get the most out of your
expensive SAN.

I read a comment earlier about setting block sizes to 8k to math pg's block size. Seems to make
sense, you should check it out.

Have fun,
Mr Pink

--- Anjan Dave <adave(at)vantage(dot)com> wrote:

> Hello,
> 
>  
> 
> I'll be moving a DB from internal RAID-10 SCSI storage to an EMC CX300
> FC RAID-10 LUN, bound to the host. I've setup a test host machine and a
> test LUN. The /var/lib/pgsql/data folder is sym-linked to a partition on
> the LUN. 
> 
>  
> 
> Other than the shared_buffers, effective cache size, and sort memory, I
> am not sure if I need to change any other parameters in the
> postgresql.conf file for getting maximum performance from the EMC box.
> 
>  
> 
> Is there a general guideline for setting up postgres database and the
> tunable parameters on a SAN, especially for EMC?
> 
>  
> 
> Appreciate any help,
> 
>  
> 
> Thanks,
> Anjan
> 
> 



	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 

In response to

pgsql-performance by date

Next:From: Patrick HatcherDate: 2004-09-23 16:32:50
Subject: Re: vacuum full & max_fsm_pages question
Previous:From: Mr PinkDate: 2004-09-23 15:29:25
Subject: Re: Caching of Queries

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