Re: Tablespaces and NFS - Mailing list pgsql-performance

From Carlos Moreno
Subject Re: Tablespaces and NFS
Date
Msg-id 46F273A8.8060209@mochima.com
Whole thread Raw
In response to Re: Tablespaces and NFS  ("Peter Koczan" <pjkoczan@gmail.com>)
Responses Re: Tablespaces and NFS  ("Peter Koczan" <pjkoczan@gmail.com>)
List pgsql-performance
>
> About 5 months ago, I did an experiment serving tablespaces out of
> AFS, another shared file system.
>
> You can read my full post at
> http://archives.postgresql.org/pgsql-admin/2007-04/msg00188.php

Thanks for the pointer!   I had done a search on the archives, but
didn't find this one  (strange, since I included the keywords
tablespace and NFS, both of which show up in your message).

Anyway...  One detail I don't understand --- why do you claim that
"You can't take advantage of the shared file system because you can't
share tablespaces among clusters or servers" ???

With NFS, I could mount, say, /mnt/nfs/fs1 to be served by NFS
server #1, and then create tablespace nfs1 location '/mnt/nfs/fs1' ...
Why wouldn't that work??  (or was the comment specific to AFS?)

BTW, I'm not too worried by the lack of security with NFS, since
both the "main" postgres machine and the potential NFS servers
that I would use would be completely "private" machines (in that
there are no users and no other services are running in there).
I would set up a strict firewall policy so that the NFS server
only accepts connections from the main postgres machine.

Back to your comment:

> On the whole, you're not going to see a performance improvement
> running tablespaces on NFS (unless the disk system on the NFS server
> is a lot faster)

This seems to be the killer point --- mainly because the network
connection is a 100Mbps  (around 10 MB/sec --- less than 1/4 of
the performance we'd expect from an internal hard drive).  If at
least it was a Gigabit connection, I might still be tempted to
retry the experiment.  I was thinking that *maybe* the latencies
and contention due to heads movements (in the order of the millisec)
would take precedence and thus, a network-distributed cluster of
hard drives would end up winning.


> P.S. Why not just set up those servers you're planning on using as NFS
> shares as your postgres server(s)?

We're clear that that would be the *optimal* solution --- problem
is, there's a lot of client-side software that we would have to
change;  I'm first looking for a "transparent" solution in which
I could distribute the load at a hardware level, seeing the DB
server as a single entity --- the ideal solution, of course,
being the use of tablespaces with 4 or 6 *internal* hard disks
(but that's not an option with our current web hoster).

Anyway, I'll keep working on alternative solutions --- I think
I have enough evidence to close this NFS door.

Thanks!


pgsql-performance by date:

Previous
From: Jean-David Beyer
Date:
Subject: Re: Low CPU Usage
Next
From: "Carlo Stonebanks"
Date:
Subject: REPOST: Performance improves only after repeated VACUUM/ANALYZE