Re: Tuning Postgres 9.1 on Windows - Mailing list pgsql-performance

From Walker, James Les
Subject Re: Tuning Postgres 9.1 on Windows
Date
Msg-id 21BFB59709EBB84DB412ED7F739FFD3B1AC403@TBPINFN0203.cad.local
Whole thread Raw
In response to Re: Tuning Postgres 9.1 on Windows  (Merlin Moncure <mmoncure@gmail.com>)
Responses Re: Tuning Postgres 9.1 on Windows  (Merlin Moncure <mmoncure@gmail.com>)
Re: Tuning Postgres 9.1 on Windows  (Thomas Kellerer <spam_eater@gmx.net>)
List pgsql-performance
I installed the enterprisedb distribution and immediately saw a 400% performance increase. Turning off fsck made it an
orderof magnitude better. I'm now peaking at over 400 commits per second. Does that sound right? 

If I understand what you're saying, then to sustain this high rate I'm going to need a controller that can defer fsync
requestsfrom the host because it has some sort of battery backup that guarantees the full write. 

-- Les

-----Original Message-----
From: Merlin Moncure [mailto:mmoncure@gmail.com]
Sent: Tuesday, May 01, 2012 9:43 AM
To: Walker, James Les
Cc: Thomas Kellerer; pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Tuning Postgres 9.1 on Windows

On Tue, May 1, 2012 at 8:14 AM, Walker, James Les <JAWalker@cantor.com> wrote:
> SSD is OCZ-VERTEX3 MI. Controller is LSI SAS2 2008 Falcon. I'm working on installing EDB. Then I can give you some
I/Onumbers. 

It looks like the ssd doesn't have a nv cache and the raid card is a simple sas hba (which likely isn't doing much for
thessd besides masking TRIM).  The OCZ 'pro' versions are the ones with power loss protection (see: 
http://hothardware.com/Reviews/OCZ-Vertex-3-Pro-SandForce-SF2000-Based-SSD-Preview/).
 Note the bullet: "Implements SandForce 2582 Controller with power loss data protection".  It doesn't look like the
Vertex3 Pro is out yet. 

If my hunch is correct, the issue here is that the drive is being asked to sync data physically and SSD really don't
performwell when the controller isn't in control of when and how to sync data.  However full physical sync is the only
wayto guarantee data is truly safe in the context of a unexpected power loss (an nv cache is basically a compromise on
thispoint). 

merlin
CONFIDENTIAL: This e-mail, including its contents and attachments, if any, are confidential. If you are not the named
recipientplease notify the sender and immediately delete it. You may not disseminate, distribute, or forward this
e-mailmessage or disclose its contents to anybody else. Copyright and any other intellectual property rights in its
contentsare the sole property of Cantor Fitzgerald. 
     E-mail transmission cannot be guaranteed to be secure or error-free. The sender therefore does not accept
liabilityfor any errors or omissions in the contents of this message which arise as a result of e-mail transmission.
Ifverification is required please request a hard-copy version. 
     Although we routinely screen for viruses, addressees should check this e-mail and any attachments for viruses. We
makeno representation or warranty as to the absence of viruses in this e-mail or any attachments. Please note that to
ensureregulatory compliance and for the protection of our customers and business, we may monitor and read e-mails sent
toand from our server(s).  

For further important information, please see  http://www.cantor.com/legal/statement


pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: Any disadvantages of using =ANY(ARRAY()) instead of IN?
Next
From: Clemens Eisserer
Date:
Subject: Re: Any disadvantages of using =ANY(ARRAY()) instead of IN?