Thread: performance issues on windows with 8.3.0?
Are there any known regression issues WRT performance on the 8.3.0.1 binary build for windows? And I mean serious -multiple orders of magnitude- performance issues running simple queries on a small database... A little more background. I built 8.3.0 on Cent OS 5 today. Started using it with a server application that I have to do some benchmarking. Java application connecting via jdbc to Postgres on localhost. Everything looked great. Perhaps even faster than 8.2 - but I don't have the benchmarks to say for sure yet. Then, I wanted to test what is usually our fastest performing setup - with the database on a second system. So, I installed the new 8.3 on a Windows 2003 system, started it up, created my database, pointed my java app to it and everything seemed good. Then I put a load on it - and my server thru-put went from about 1500 messages per second on the linux-localhost combination to 30 on the remote windows postgres installation. I will be investigating this much more completely first thing tomorrow - but I figured I'd ask to see if there was something obvious first... Thanks, Dan
So, my ill Postgres 8.3 database is filling up log files in the pg_log directory with the following: 2008-02-13 18:29:31 CST LOG: loaded library "$libdir/plugins/plugin_debugger.dll" 2008-02-13 18:29:31 CST LOG: loaded library "$libdir/plugins/plugin_debugger.dll" 2008-02-13 18:29:31 CST LOG: loaded library "$libdir/plugins/plugin_debugger.dll" 2008-02-13 18:29:31 CST LOG: loaded library "$libdir/plugins/plugin_debugger.dll" 2008-02-13 18:29:31 CST LOG: loaded library "$libdir/plugins/plugin_debugger.dll" 2008-02-13 18:29:31 CST LOG: loaded library "$libdir/plugins/plugin_debugger.dll" 2008-02-13 18:29:31 CST LOG: loaded library "$libdir/plugins/plugin_debugger.dll" 2008-02-13 18:29:31 CST LOG: loaded library "$libdir/plugins/plugin_debugger.dll" 2008-02-13 18:29:31 CST LOG: loaded library "$libdir/plugins/plugin_debugger.dll" 2008-02-13 18:29:31 CST LOG: loaded library "$libdir/plugins/plugin_debugger.dll" 2008-02-13 18:29:31 CST LOG: loaded library "$libdir/plugins/plugin_debugger.dll" Does this mean anything to anyone? I can't hardly believe that I'm the first one to notice that the windows build of 8.3 has serious issues. Thanks, Dan
Dan Armbrust wrote: > Are there any known regression issues WRT performance on the 8.3.0.1 > binary build for windows? > > And I mean serious -multiple orders of magnitude- performance issues > running simple queries on a small database... > > A little more background. I built 8.3.0 on Cent OS 5 today. Started > using it with a server application that I have to do some > benchmarking. Java application connecting via jdbc to Postgres on > localhost. Everything looked great. Perhaps even faster than 8.2 - > but I don't have the benchmarks to say for sure yet. > > Then, I wanted to test what is usually our fastest performing setup - > with the database on a second system. So, I installed the new 8.3 on > a Windows 2003 system, started it up, created my database, pointed my > java app to it and everything seemed good. > > Then I put a load on it - and my server thru-put went from about 1500 > messages per second on the linux-localhost combination to 30 on the > remote windows postgres installation. > > I will be investigating this much more completely first thing tomorrow > - but I figured I'd ask to see if there was something obvious first... How's the performance compared to 8.2 on the same machine? From what you're saying, I take it you already have that there? If not, you need to look at a whole lot of more things. It *will* be slower on windows than on linux, and significantly so, but it shouldn't be several orders of magnitude. But you need to narrow down the testing a bit - for example, one of your tests runs over the network and one runs locally, so that could be where your issues is. It could also be that your harddrives under linux is lying about fsync, whereas the windows version will by default write through such write caches even if they exist. There are many different things that could be the reason here. //Magnus
On Thu, Feb 14, 2008 at 7:56 PM, Dan Armbrust <daniel.armbrust.list@gmail.com> wrote: > On Thu, Feb 14, 2008 at 1:31 PM, Dave Page <dpage@pgadmin.org> wrote: > > > You must have enabled the debugger when you installed (or didn't > > disable it). You can turn it back off in postgresql.conf if you like - > > there may be a little overhead. > > I see this in the postgresql.conf file: > shared_preload_libraries = '$libdir/plugins/plugin_debugger.dll' # > (change requires restart) Yup, just set it blank and restart. > I didn't turn that on, perhaps I missed it in the installer, or it > defaults to on in the installer. I commented it out, and now my > performance on 8.3 on windows is in line with what I am seeing with > 8.2.6 on windows. That is a lot of overhead, when a connection is > made (I realize I shouldn't be making connections this often - but I > wonder if the overhead is only at connection time, or if there is > other overhead as well) I'm surprised there's so much overhead, but not that there is some. Any runtime overhead will be in pl/pgsql functions so if you're not using any, you won't see any difference once connected. > > However, the fact that it keeps appearing implies you're using lots of > > new (short-lived?) connections. That's particularly expensive on > > Windows - consider a connection pooler, of if you're using something > > like php, persistent connections. > > > Your right, my connections are dropping off left and right. My > performance on windows is about 75% slower than the performance on > linux. It appears that I'm currently dropping connections on both > windows and linux. Does that fall in line with your expectation that > creating connections on windows is particularly expensive? I couldn't quote a figure, but I'm not surprised it's noticeably slower. > I'll go figure out why on earth my connections are getting killed and > recreated by the pooling layers. Sounds like a good plan :-) -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com The Oracle-compatible database company
Thanks for all the help. Performance is back where I thought it should be, after I fixed our pooling bug. I didn't think that postgres would be released with performance issues like that - its just too good :) Thanks, Dan