Обсуждение: Tuning Postgres 9.1 on Windows
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
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
On Mon, Apr 30, 2012 at 8:49 AM, Walker, James Les <JAWalker@cantor.com> 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
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).
On Mon, Apr 30, 2012 at 5:00 PM, Thomas Kellerer <spam_eater@gmx.net> 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
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: pgsql-performance-owner@postgresql.org [mailto:pgsql-performance-owner@postgresql.org] On Behalf Of Merlin Moncure Sent: Monday, April 30, 2012 6:04 PM To: Thomas Kellerer Cc: pgsql-performance@postgresql.org Subject: Re: [PERFORM] Tuning Postgres 9.1 on Windows On Mon, Apr 30, 2012 at 5:00 PM, Thomas Kellerer <spam_eater@gmx.net> 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 (pgsql-performance@postgresql.org) 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
On Tue, May 1, 2012 at 7:51 AM, Walker, James Les <JAWalker@cantor.com> 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
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:mmoncure@gmail.com]
Sent: Tuesday, May 01, 2012 9:07 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 7:51 AM, Walker, James Les <JAWalker@cantor.com> 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
On 5/1/2012 8:06 AM, Merlin Moncure wrote: > On Tue, May 1, 2012 at 7:51 AM, Walker, James Les<JAWalker@cantor.com> 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
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 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
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
On Tue, May 1, 2012 at 9:44 AM, Walker, James Les <JAWalker@cantor.com> 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
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
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: pgsql-performance-owner@postgresql.org [mailto:pgsql-performance-owner@postgresql.org] On Behalf Of Thomas Kellerer Sent: Tuesday, May 01, 2012 1:00 PM To: pgsql-performance@postgresql.org 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 (pgsql-performance@postgresql.org) 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
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: pgsql-performance-owner@postgresql.org [mailto:pgsql-performance-owner@postgresql.org] On Behalf Of Walker, James Les Sent: Tuesday, May 01, 2012 3:14 PM To: 'Thomas Kellerer'; pgsql-performance@postgresql.org 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: pgsql-performance-owner@postgresql.org [mailto:pgsql-performance-owner@postgresql.org] On Behalf Of Thomas Kellerer Sent: Tuesday, May 01, 2012 1:00 PM To: pgsql-performance@postgresql.org 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 (pgsql-performance@postgresql.org) 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 (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance