Andreas Brandl wrote:
Hi Andreas,
Thanks for taking a look at this.
Yes, in fact, running the same benchmark but re-opening the connection for
every SELECT does make a difference. I prepared an comparison chart showing the
timeline for either test-modes. [1]
By re-opening a connection, you force PostgreSQL to release all of its
internal memory (including that used by PostGIS) and create a new
process to service the request. So it doesn't rule out the possibility
of some kind of memory leak somewhere.
"test1" (on the left) shows the query times working with a single Connection
for all tests. The described effect may not be overlooked IMO.
"test2" (on the right) shows same tests with the mode suggested by Mark
(re-opening Connection). Here the effect does not show up.
Both test1, test2 were run on the same machine (2 GB RAM, core 2 duo) and same
configuration, which may be found here [2]. Config is a tuned default config
(changed shared_buffers=128MB, work_mem=10MB, effective_cache_size=1500MB).
BTW: Tuning the postgresql.conf resulted in overall better results (as expected) but had no impact on this effect.
I would really appreciate any insight on this behaviour. Next I'm going to run
the benchmark on a linux OS.
As a quick test, I would suggest upgrading to the new Windows
StackBuilder packages since they contain GEOS 3.2.0 which had a number
of memory leaks fixed and see if you see the same behaviour on Test 1,
i.e. slowly increasing query times.
I'd also be interested to see your results of just Test 1 on a Linux OS
too to see whether it is an OS specific issue that you are seeing.
ATB,
Mark.
--
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063
Sirius Labs: http://www.siriusit.co.uk/labs
_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
