Re: [PERFORM] [sfpug] DATA directory on network attached storage

[Aditya]

On Fri, Apr 08, 2005 at 10:01:55AM -0700, Jeff Frost wrote:
> We are currently considering the possibility of creating a warm standby 
> machine utilizing heartbeat and a network attached storage device for the 
> DATA directory.  The idea being that the warm standby machine has its 
> postmaster stopped.  When heartbeat detects the death of the master server, 
> the postmaster is started up on the warm standby using the shared DATA 
> directory. Other than the obvious problems of both postmasters 
> inadvertently attempting access at the same time, I'm curious to know if 
> anyone has tried any similar setups and what the experiences have been.  
> Specifically is the performance of gigE good enough to allow postgres to 
> perform under load with an NFS mounted DATA dir?  Are there other problems 
> I haven't thought about?  Any input would be greatly appreciated.

We (Zapatec Inc) have been running lots of Pg dbs off of a Network Appliance
fileserver (NFS TCPv3) with FreeBSD client machines for several years now with
no problems AFAICT other than insufficient bandwidth between servers and the
fileserver (for one application, www.fastbuzz.com, 100baseTX (over a private
switched network) was insufficient, but IDE-UDMA was fine, so GigE would have
worked too, but we couldn't justify purchasing a new GigE adapter for our
Netapp).

We have the same setup as you would like, allowing for warm standby(s),
however we haven't had to use them at all.

We have not, AFAICT, had any problems with the traffic over NFS as far as
reliability -- I'm sure there is a performance penalty, but the reliability
and scalability gains more than offset that.

FWIW, if I were to do this anew, I would probably opt for iSCSI over GigE with
a NetApp.

Adi

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings

Re: [PERFORM] [sfpug] DATA directory on network attached storage

[Aditya]

On Mon, Apr 11, 2005 at 10:59:51AM -0700, Joe Conway wrote:
> >FWIW, if I were to do this anew, I would probably opt for iSCSI over GigE 
> >with
> >a NetApp.
> 
> Any particular reason? Our NetApp technical rep advised nfs over iSCSI, 
> IIRC because of performance.

I would mount the Netapp volume(s) as a block level device on my server using
iSCSI (vs. a file-based device like NFS) so that filesystem parameters could
be more finely tuned and one could really make use of jumbo frames over GigE.

But that level of tuning depends on load after all and with a Netapp you can
have both, so maybe start with having your databases on an NFS volume on the
Netapp, and when you have a better idea of the tuning requirements, move it
over to a iSCSI LUN.

I'm not sure I understand why NFS would perform better than iSCSI -- in any
case, some large Oracle dbs at my current job are moving to iSCSI on Netapp
and in that environment both Oracle and Netapp advise iSCSI (probably because
Oracle uses the block-level device directly), so I suspend the difference in
performance is minimal.

Adi

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

[PERFORM] LIKE search with ending % not optimized in v8

[Aditya Damle]

Hello. I believe in earlier versions, a query of the
form 
select attrib from ttt where attrib like 'foo%' would
be able to take advantage of an index. I have seen
this in the past. Currently I am using v8.0.3. From
what I can see is that the execultion plan seems to
use a seq scan and to totally ignore the index. Is
this the case?

-Aditya


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]