Обсуждение: Tuning Postgres 9.1 on Windows

От:
"Walker, James Les"
Дата:

I’m trying to benchmark Postgres vs. several other databases on my workstation. My workstation is running 64 bit Windows 7. It has 12 gb of RAM and a W3550 @ 3 Ghz. I installed Postgres 9.1 using the windows installer. The data directory is on a 6Gb/s SATA SSD.

 

My application is multithreaded and uses pooled connections via JDBC. It’s got around 20 threads doing asynchronous transactions against the database. It’s about 70% read/30% write. Transactions are very small. There are no long-running transactions. I start with an empty database and I only run about 5,000 business transactions in my benchmark. That results in 10,000 – 15,000 commits.

 

When I first installed Postgres I did no tuning at all and was able to get around 40 commits per-second which is quite slow. I wanted to establish a top-end so I turned off synchronous commit and ran the same test and got the same performance of 40 commits per second. I turned on the “large system cache” option on Windows 7 and got the same results. There seems to be some resource issues that’s limiting me to 40 commits per second but I can’t imagine what it could be or how to detect it.

 

I’m not necessarily looking for advice on how to increase performance, but I at least need to know how to find the bottleneck.

 

-- Les Walker

 

CONFIDENTIAL: This e-mail, including its contents and attachments, if any, are confidential. If you are not the named recipient please notify the sender and immediately delete it. You may not disseminate, distribute, or forward this e-mail message or disclose its contents to anybody else. Copyright and any other intellectual property rights in its contents are the sole property of Cantor Fitzgerald.
    E-mail transmission cannot be guaranteed to be secure or error-free. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission.  If verification 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 make no representation or warranty as to the absence of viruses in this e-mail or any attachments. Please note that to ensure regulatory compliance and for the protection of our customers and business, we may monitor and read e-mails sent to and from our server(s).

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

От:
Andy Colson
Дата:

On 4/30/2012 8:49 AM, Walker, James Les wrote:
> I’m trying to benchmark Postgres vs. several other databases on my
> workstation. My workstation is running 64 bit Windows 7. It has 12 gb of
> RAM and a W3550 @ 3 Ghz. I installed Postgres 9.1 using the windows
> installer. The data directory is on a 6Gb/s SATA SSD.
>
> My application is multithreaded and uses pooled connections via JDBC.
> It’s got around 20 threads doing asynchronous transactions against the
> database. It’s about 70% read/30% write. Transactions are very small.
> There are no long-running transactions. I start with an empty database
> and I only run about 5,000 business transactions in my benchmark. That
> results in 10,000 – 15,000 commits.
>
> When I first installed Postgres I did no tuning at all and was able to
> get around 40 commits per-second which is quite slow. I wanted to
> establish a top-end so I turned off synchronous commit and ran the same
> test and got the same performance of 40 commits per second. I turned on
> the “large system cache” option on Windows 7 and got the same results.
> There seems to be some resource issues that’s limiting me to 40 commits
> per second but I can’t imagine what it could be or how to detect it.
>
> I’m not necessarily looking for advice on how to increase performance,
> but I at least need to know how to find the bottleneck.
>
> -- Les Walker
>

One thing I'd look at is your hardware and determine if you are CPU
bound or IO bound.  I use Linux so don't know how you'd do that on windows.

Have you checked your sql statements with "explain analyze"?

I don't know anything about config file settings on windows, but on
Linux its really important.  google could probably help you there.

Knowing if you are CPU bound or IO bound, and if you have any bad plans,
will tell you what config file changes to make.

-Andy


От:
Merlin Moncure
Дата:

On Mon, Apr 30, 2012 at 8:49 AM, Walker, James Les <> wrote:
> I’m trying to benchmark Postgres vs. several other databases on my
> workstation. My workstation is running 64 bit Windows 7. It has 12 gb of RAM
> and a W3550 @ 3 Ghz. I installed Postgres 9.1 using the windows installer.
> The data directory is on a 6Gb/s SATA SSD.
>
>
>
> My application is multithreaded and uses pooled connections via JDBC. It’s
> got around 20 threads doing asynchronous transactions against the database.
> It’s about 70% read/30% write. Transactions are very small. There are no
> long-running transactions. I start with an empty database and I only run
> about 5,000 business transactions in my benchmark. That results in 10,000 –
> 15,000 commits.
>
>
>
> When I first installed Postgres I did no tuning at all and was able to get
> around 40 commits per-second which is quite slow. I wanted to establish a
> top-end so I turned off synchronous commit and ran the same test and got the
> same performance of 40 commits per second. I turned on the “large system
> cache” option on Windows 7 and got the same results. There seems to be some
> resource issues that’s limiting me to 40 commits per second but I can’t
> imagine what it could be or how to detect it.
>
>
>
> I’m not necessarily looking for advice on how to increase performance, but I
> at least need to know how to find the bottleneck.

It's almost certainly coming from postgres being anal about making
sure the data is syncing all the way back to the ssd through all the
buffers.  Although ssd are quite fast, if you run them this way they
are no better than hard drives.  Trying turning off fsync in
postgrsql.conf to be sure.  If you're still seeing poor performance,
try posting and explain analyze of the queries you think might be
slowing you down.

Also, which ssd?

merlin

От:
Thomas Kellerer
Дата:

Merlin Moncure wrote on 30.04.2012 23:43:
> Trying turning off fsync in postgrsql.conf to be sure.

This is a dangerous advise.
Turning off fsync can potentially corrupt the database in case of a system failure (e.g. power outage).





От:
Merlin Moncure
Дата:

On Mon, Apr 30, 2012 at 5:00 PM, Thomas Kellerer <> wrote:
> Merlin Moncure wrote on 30.04.2012 23:43:
>
>> Trying turning off fsync in postgrsql.conf to be sure.
>
>
> This is a dangerous advise.
> Turning off fsync can potentially corrupt the database in case of a system
> failure (e.g. power outage).
>

sure. that said, we're just trying to figure out why he's getting
around 40tps.   since he's only benchmarking test data it's perfectly
ok to do that.

merlin

От:
"Walker, James Les"
Дата:

Exactly, if turning off fsync gives me 100 commits/sec then I know where my bottleneck is and I can attack it. Keep in
mindthough that I already turned off synchronous commit -- *really* dangerous -- and it didn't have any effect. 

-- Les

-----Original Message-----
From:  [mailto:] On Behalf Of Merlin
Moncure
Sent: Monday, April 30, 2012 6:04 PM
To: Thomas Kellerer
Cc: 
Subject: Re: [PERFORM] Tuning Postgres 9.1 on Windows

On Mon, Apr 30, 2012 at 5:00 PM, Thomas Kellerer <> wrote:
> Merlin Moncure wrote on 30.04.2012 23:43:
>
>> Trying turning off fsync in postgrsql.conf to be sure.
>
>
> This is a dangerous advise.
> Turning off fsync can potentially corrupt the database in case of a
> system failure (e.g. power outage).
>

sure. that said, we're just trying to figure out why he's getting
around 40tps.   since he's only benchmarking test data it's perfectly
ok to do that.

merlin

--
Sent via pgsql-performance mailing list ()
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
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


От:
Merlin Moncure
Дата:

On Tue, May 1, 2012 at 7:51 AM, Walker, James Les <> wrote:
> Exactly, if turning off fsync gives me 100 commits/sec then I know where my bottleneck is and I can attack it. Keep
inmind though that I already turned off synchronous commit -- *really* dangerous -- and it didn't have any effect. 

well synchronous commit is not as dangerous:
fsync off + power failure = corrupt database
synchronous commit off + power failure = some lost transactions

still waiting on the ssd model #.  worst case scenario is that you tps
rate is in fact sync bound and you have a ssd without capacitor backed
buffers (for example, the intel 320 has them); the probable workaround
would be to set the drive cache from write through to write back but
it would unsafe in that case.  in other words, tps rates in the triple
digits would be physically impossible.

another less likely scenario is you are having network issues
(assuming you are connecting to the database through tcp/ip).  20
years in, microsoft is still figuring out how to properly configure a
network socket.

merlin

От:
"Walker, James Les"
Дата:

SSD is OCZ-VERTEX3 MI. Controller is LSI SAS2 2008 Falcon. I'm working on installing EDB. Then I can give you some I/O
numbers.

-- Les

-----Original Message-----
From: Merlin Moncure [mailto:]
Sent: Tuesday, May 01, 2012 9:07 AM
To: Walker, James Les
Cc: Thomas Kellerer; 
Subject: Re: [PERFORM] Tuning Postgres 9.1 on Windows

On Tue, May 1, 2012 at 7:51 AM, Walker, James Les <> wrote:
> Exactly, if turning off fsync gives me 100 commits/sec then I know where my bottleneck is and I can attack it. Keep
inmind though that I already turned off synchronous commit -- *really* dangerous -- and it didn't have any effect. 

well synchronous commit is not as dangerous:
fsync off + power failure = corrupt database synchronous commit off + power failure = some lost transactions

still waiting on the ssd model #.  worst case scenario is that you tps rate is in fact sync bound and you have a ssd
withoutcapacitor backed buffers (for example, the intel 320 has them); the probable workaround would be to set the
drivecache from write through to write back but it would unsafe in that case.  in other words, tps rates in the triple
digitswould be physically impossible. 

another less likely scenario is you are having network issues (assuming you are connecting to the database through
tcp/ip). 20 years in, microsoft is still figuring out how to properly configure a network socket. 

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


От:
Andy Colson
Дата:

On 5/1/2012 8:06 AM, Merlin Moncure wrote:
> On Tue, May 1, 2012 at 7:51 AM, Walker, James Les<>  wrote:
>> Exactly, if turning off fsync gives me 100 commits/sec then I know where my bottleneck is and I can attack it. Keep
inmind though that I already turned off synchronous commit -- *really* dangerous -- and it didn't have any effect. 
>
> well synchronous commit is not as dangerous:
> fsync off + power failure = corrupt database
> synchronous commit off + power failure = some lost transactions
>
> still waiting on the ssd model #.  worst case scenario is that you tps
> rate is in fact sync bound and you have a ssd without capacitor backed
> buffers (for example, the intel 320 has them); the probable workaround
> would be to set the drive cache from write through to write back but
> it would unsafe in that case.  in other words, tps rates in the triple
> digits would be physically impossible.
>
> another less likely scenario is you are having network issues
> (assuming you are connecting to the database through tcp/ip).  20
> years in, microsoft is still figuring out how to properly configure a
> network socket.
>
> merlin
>

Even if its all local, windows doesnt have domain sockets (correct?), so
all that traffic still has to go thru some bit of network stack, yes?

-Andy

От:
Merlin Moncure
Дата:

On Tue, May 1, 2012 at 8:14 AM, Walker, James Les <> 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 the ssd 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 Vertex 3 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 perform well when
the controller isn't in control of when and how to sync data.  However
full physical sync is the only way to guarantee data is truly safe in
the context of a unexpected power loss (an nv cache is basically a
compromise on this point).

merlin

От:
"Walker, James Les"
Дата:

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:]
Sent: Tuesday, May 01, 2012 9:43 AM
To: Walker, James Les
Cc: Thomas Kellerer; 
Subject: Re: [PERFORM] Tuning Postgres 9.1 on Windows

On Tue, May 1, 2012 at 8:14 AM, Walker, James Les <> 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


От:
Merlin Moncure
Дата:

On Tue, May 1, 2012 at 9:44 AM, Walker, James Les <> wrote:
> I installed the enterprisedb distribution and immediately saw a 400% performance increase. Turning off fsck made it
anorder of magnitude better. I'm now peaking at over 400 commits per second. Does that sound right? 

yeah -- well it's hard to say but that sounds plausible based on what
i know.  it would be helpful to see the queries you're running to get
apples to apples idea of what's going on.

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

yes --  historically, they way to get your tps rate up was to get a
battery backed cache.  this can give you burst (although not
necessarily sustained) tps rates well above what the drive can handle.
 lately, a few of the better built ssd also have on board capacitors
which provide a similar function and allow the drives to safely hit
high tps rates as well.  take a good look at the intel 320 and 710
drives.

merlin

От:
Thomas Kellerer
Дата:

Walker, James Les wrote on 01.05.2012 16:44:
> I installed the enterprisedb distribution and immediately saw a 400% performance increase.

What exactly is "the enterprisedb distribution"?
Are you talking about the the Advanced Server?

I would be very surprised if the code base would differ so much to allow such a performance gain.
Could it be that the default settings for the Advanced Server are different than those of the "community edition"?

And what did you have installed before that? (as the Windows binary are always distributed by EnterpriseDB)

Thomas

От:
"Walker, James Les"
Дата:

Yes. I didn't know the proper vernacular :-)

It is very likely that the default settings are different. I'm looking at that right now.

-- Les Walker

-----Original Message-----
From:  [mailto:] On Behalf Of Thomas
Kellerer
Sent: Tuesday, May 01, 2012 1:00 PM
To: 
Subject: Re: [PERFORM] Tuning Postgres 9.1 on Windows

Walker, James Les wrote on 01.05.2012 16:44:
> I installed the enterprisedb distribution and immediately saw a 400% performance increase.

What exactly is "the enterprisedb distribution"?
Are you talking about the the Advanced Server?

I would be very surprised if the code base would differ so much to allow such a performance gain.
Could it be that the default settings for the Advanced Server are different than those of the "community edition"?

And what did you have installed before that? (as the Windows binary are always distributed by EnterpriseDB)

Thomas


--
Sent via pgsql-performance mailing list ()
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
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


От:
"Walker, James Les"
Дата:

Turns out the 40% was due to a configuration problem with my application. I'm now getting the same performance with
communityedition. 

It appears that I'm now CPU bound. My CPU's are all pegged.

-- Les Walker

-----Original Message-----
From:  [mailto:] On Behalf Of Walker, James
Les
Sent: Tuesday, May 01, 2012 3:14 PM
To: 'Thomas Kellerer'; 
Subject: Re: [PERFORM] Tuning Postgres 9.1 on Windows

Yes. I didn't know the proper vernacular :-)

It is very likely that the default settings are different. I'm looking at that right now.

-- Les Walker

-----Original Message-----
From:  [mailto:] On Behalf Of Thomas
Kellerer
Sent: Tuesday, May 01, 2012 1:00 PM
To: 
Subject: Re: [PERFORM] Tuning Postgres 9.1 on Windows

Walker, James Les wrote on 01.05.2012 16:44:
> I installed the enterprisedb distribution and immediately saw a 400% performance increase.

What exactly is "the enterprisedb distribution"?
Are you talking about the the Advanced Server?

I would be very surprised if the code base would differ so much to allow such a performance gain.
Could it be that the default settings for the Advanced Server are different than those of the "community edition"?

And what did you have installed before that? (as the Windows binary are always distributed by EnterpriseDB)

Thomas


--
Sent via pgsql-performance mailing list ()
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
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


--
Sent via pgsql-performance mailing list ()
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance