Paul,
took your advice and installed Geos 3.2.0.
Index is now running for 14 hrs, postmaster is taking all the RAM.
Sadly it looks like the Geos update didn't save me.
Regards
Frans
2010/3/28 Paul Ramsey pram...@cleverelephant.ca:
GEOS 3.2 is backwards compatible, so you can install it overtop
Paul,
I have checked the different kinds of data in the table for their memory usage.
ST_LineSting is the one that's leaking, the other types complete
indexing without leakage.
Update to Geos 3.2.0 didn't improve the operation.
Kind regards
Frans
2010/3/28 Paul Ramsey pram...@cleverelephant.ca
in turn and
watch the memory usage.
If indexing starts sequentially from the beginning to the end, we
reach ST_Point around row 22.000.000. This is from the count of
geometry operations exactly where the slowdown begins.
Does this track us to the leak?
Thanks regards
Frans
2010/3/26 Paul Ramsey
restoring the dump.
Thanks
Frans
2010/3/26 Paul Ramsey pram...@cleverelephant.ca:
Occams razor says it's PostGIS. However, I'm concerned about how old
the code being run is. In particular, the library underneath PostGIS,
GEOS, had a *lot* of memory work done on it over the last year. I'd
like to see
Operation is now running for around 13 hrs.
Two postmaster processes above 1% memory usage are running.
One of them uses constantly 26.5% of memory.
The other one is growing:
After 1 hr25%
After 9 hrs 59%
After 13 hrs64%
Thanks regards
Frans
2010/3/25 Frans Hals fha
, you suggest me
to do.
Kind regards
Frans
2010/3/26 Tom Lane t...@sss.pgh.pa.us:
Well, it's pretty clear that you've found a memory leak, but that was
what we thought before; this data doesn't move us any closer to a fix.
In particular it's not possible to guess whether the leak should be
blamed
The index mentioned below has been created in some minutes without problems.
Dropped it and created it again. Uses around 36 % of memorywhile
creating, after completion postmaster stays at 26 %.
I'm not sure, what you're thinking about generating a self-contained
test that exhibits similar
5 x postmaster taking memory:
93.3 %
18.7 %
0.3 %
0.2 %
0.0 %
112.5%
Looks like there is someone living beyond its means?
Frans
2010/3/24 Tom Lane t...@sss.pgh.pa.us:
Hm. I wonder about a memory leak in there somewhere. Have you checked
the process size while this is going
Is there anything meaningful for you?
Does it makes sense to install the debuginfos to catch the problem? If
yes, I may do so.
Paul asked me, to check another function of the postgis set for a
memory leak. I will try this now.
Thanks regards
Frans
2010/3/24 Tom Lane t...@sss.pgh.pa.us:
Can you
Paul,
I have started the operation right now after a fresh reboot of the machine.
update placex set leakcheck = st_x(st_centroid(geometry));
Please give me some time to collect the results...
Thanks regards
Frans
2010/3/25 Paul Ramsey pram...@cleverelephant.ca:
If you build an index, or try
.
Anybody out there has an idea what happens or better how to reach the
50.000.000?
Thanks
Frans
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
, Frans wrote:
I'm using Fedora Core 2, apache 2.0 and postgresql 7.4.6.
Recently, the application is slowing down. When I check the process
using top, sometimes postmaster process time is increasing and the
process is never end, I think this cause the application slowing down
the server slowing down and I have to
restart postmaster.
Is there somebody who experience the same problem? and what is the solution?
Thank You,
Frans
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
group by name;
This yields the message: 'Aggregates not allowed in WHERE clause'.
Can somebody help me here
thx,
Frans
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs
,
Frans Gunawan
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
' , but the result is
'1900-01-01 00:00:00'::timestamp without time zone
I've tried to erase the ::timestamp withut time zone but it didn't work.
this problem never occurs in postgresql 7.3.4.
Is there any solusion for my problem?
thanks
--
Best Regards,
Frans Gunawan
[EMAIL PROTECTED
16 matches
Mail list logo
