Re: Performance on 8CPU's and 32GB of RAM - Mailing list pgsql-performance

From Scott Marlowe
Subject Re: Performance on 8CPU's and 32GB of RAM
Date
Msg-id dcc563d10709051229q28767cbtc61a5af11447faa5@mail.gmail.com
Whole thread Raw
In response to Re: Performance on 8CPU's and 32GB of RAM  ("Trevor Talbot" <quension@gmail.com>)
List pgsql-performance
On 9/5/07, Trevor Talbot <quension@gmail.com> wrote:
> On 9/5/07, Scott Marlowe <scott.marlowe@gmail.com> wrote:
> > On 9/5/07, Carlo Stonebanks <stonec.register@sympatico.ca> wrote:
> > > > Right, additionally NTFS is really nothing to use on any serious disc
> > > > array.
> > >
> > > Do you mean that I will not see any big improvement if I upgrade the disk
> > > subsystem because the client is using NTFS (i.e. Windows)
> >
> > No, I think he's referring more to the lack of reliability of NTFS
> > compared to UFS / ZFS / JFS / XFS on unixen.
>
> Lack of reliability compared to _UFS_?  Can you elaborate on this?

Not a lot.  Back when I was an NT 4.0 sysadmin, I had many many
occasions where NTFS simply corrupted for no apparent reason.  No
system crash, no obvious problems with the drive, and bang suddenly a
file goes corrupted.  About that time I gave up on Windows and started
supporting Linux and Solaris.  Neither is perfect, but I've never had
either of them just corrupt a file on good hardware for no reason.
Keep in mind, the machine that was corrupting files for no reason went
on to be our development / staging linux server, handling quite a
heavy load of developers on it, and never once had a corrupted file on
it.

With the newer journalling file systems on linux, solaris and BSD, you
get both good performance and very reliable behaviour.  Maybe NTFS has
gotten better since then, but I don't personally know.

pgsql-performance by date:

Previous
From: Ron Mayer
Date:
Subject: Re: Performance on 8CPU's and 32GB of RAM
Next
From: "Scott Marlowe"
Date:
Subject: Re: Performance on 8CPU's and 32GB of RAM