[postgis-users] strange benchmark results

[Mark Cave-Ayland]

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