NFS performance tuning

On Sun, 31 Aug 2003, Jefim M wrote:

I have the following setup for my PostgreSQL box:
4GB Ram
Dual CPU
Redhat 7.3 with 2.4.20-18.7smp kernel
2 network cards - one is dedicated to internal traffic to the NetApp filer
and other is used for other traffic

and all the Postgres database resides on the NetApp filer using NFS.
Number of the connection to the database is configured to 64.

What are best configuration setting I need to use on my PostgreSQL and Linux
boxes to get the best performance from PostgresSQL?
Are there any recomendations for the given setup (having the data on the
remote server) ?

We use a netapp and I had to muck around with the default settings under
rh7.2 to get reliable behaviour. Note that our database does not sit on a
netapp, only our semi-static web content does.

Here's the settings I added, at the behest of one of our unix / linux
ubergeeks:

timeo=10,retry=1,bg,soft,intr,rsize=8192,wsize=8192

"Scott" == scott marlowe <scott.marlowe@ihs.com> writes:

Scott> On Sun, 31 Aug 2003, Jefim M wrote:

I have the following setup for my PostgreSQL box: 4GB Ram Dual
CPU Redhat 7.3 with 2.4.20-18.7smp kernel 2 network cards - one
is dedicated to internal traffic to the NetApp filer and other
is used for other traffic

and all the Postgres database resides on the NetApp filer using
NFS. Number of the connection to the database is configured to
64.

What are best configuration setting I need to use on my
PostgreSQL and Linux boxes to get the best performance from
PostgresSQL? Are there any recomendations for the given setup
(having the data on the remote server) ?

Scott> We use a netapp and I had to muck around with the default
Scott> settings under rh7.2 to get reliable behaviour. Note that
Scott> our database does not sit on a netapp, only our semi-static
Scott> web content does.

Scott> Here's the settings I added, at the behest of one of our
Scott> unix / linux ubergeeks:

Scott> timeo=10,retry=1,bg,soft,intr,rsize=8192,wsize=8192

Argh, don't use soft mounting when the database is being accessed
through NFS and you value your data. Check out nfs.sf.net, there is a
HOWTO and FAQ for Linux NFS issues. netapp also has a very good
LInux/Netapp document written by a netapp employee who also hacks the
Linux kernel client. A google on "netapp linux howto" should find it
easily enough.

Sincerely,

Adrian Phillips

--
Who really wrote the works of William Shakespeare ?
http://www.pbs.org/wgbh/pages/frontline/shakespeare/

Is it considered safe to run postgres over nfs if the sync option is used?

Joseph Shraibman wrote:

Is it considered safe to run postgres over nfs if the sync option is used?

No, because NFS is not atomic in its operations. However, a number of
people are running PostgreSQL over NFS to network attached storage
devices, and it seems to run fine --- I just am not sure what will
happen if the network attached storage devices goes down.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian wrote:

Joseph Shraibman wrote:

Is it considered safe to run postgres over nfs if the sync option is used?

No, because NFS is not atomic in its operations. However, a number of
people are running PostgreSQL over NFS to network attached storage
devices, and it seems to run fine --- I just am not sure what will
happen if the network attached storage devices goes down.

From the FAQ at http://nfs.sourceforge.net/ :

Clients ensure that data that was written using a safe asynchronous write has been written
onto permanent storage using a new operation available in Version 3 called a COMMIT.
Servers do not send a response to a COMMIT operation until all data specified in the
request has been written to permanent storage. NFS Version 3 clients must protect buffered
data that has been written using a safe asynchronous write but not yet committed. If a
server reboots before a client has sent an appropriate COMMIT, the server can reply to the
eventual COMMIT request in a way that forces the client to resend the original write
operation. Version 3 clients use COMMIT operations when flushing safe asynchronous writes
to the server during a close(2) or fsync(2) system call, or when encountering memory pressure.

Bruce Momjian wrote:

However, a number of
people are running PostgreSQL over NFS to network attached storage
devices, and it seems to run fine --- I just am not sure what will
happen if the network attached storage devices goes down.

We also run PostgreSQL with the data-directory on a NAS. The system was
very slow. After we moved the data-dir to the database server the system
was about 20 times faster.

Does PostgreSQL have a problem with NAS?