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

Re: SAN vs Internal Disks

From: Greg Smith <gsmith(at)gregsmith(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: SAN vs Internal Disks
Date: 2007-09-07 20:04:41
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
On Fri, 7 Sep 2007, Tobias Brox wrote:

> We're also considering to install postgres on SAN - that is, my boss is
> convinced this is the right way to go.
> Advantages:
> 1. Higher I/O (at least the salesman claims so)

Shockingly, the salesman is probably lying to you.  The very concept of 
SAN says that you're putting something in between your system and the 
disks, and that something therefore must slow things down compared to 
connecting directly.  iSCSI, FC, whatever you're using as the 
communications channel can't be as fast as a controller card with a good 
interface straight into the motherboard.  For example, a PCI-E x16 disk 
controller card maxes out at 4GB/s in each direction; good luck bonding 
enough iSCSI or FC channels together to reach that transfer rate and 
getting something even remotely cost-competative with an internal card.

The cases where a SAN can improve upon performance over direct discs are 
when the comparison isn't quite fair; for example:

1) The SAN allows spreading the load over more disks than you can fit 
internally in the system
2) The SAN provides a larger memory cache than the internal cards you're 
comparing against

If you're in one of those situations, then perhaps the salesman's claim 
could have some merit.  There are lots of reasons one might want to use a 
SAN, but a higher I/O rate when fairly comparing to connecting disks 
directly is unlikely to be on that list.

* Greg Smith gsmith(at)gregsmith(dot)com Baltimore, MD

In response to

pgsql-performance by date

Next:From: Vivek KheraDate: 2007-09-07 20:35:09
Subject: Re: SAN vs Internal Disks
Previous:From: Subbiah Stalin-XCGF84Date: 2007-09-07 19:24:12
Subject: Re: Postgres with Sun Cluster HA/Solaris 10

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