Hi Gustaf
Thank you for your replays. I am a bit slow with my responses, sorry about that.
I see the same issue on all servers now - original observation that
some servers are OK was wrong.
This is due to different maxconnections configuration, which shadowed
the memory leak.
Yes - I am using
Dear Alex,
Didn't you mention earlier, that the bloat happens only on
one of your machines? Was this a wrong indication?
If you have a well behaved system, you can increase maxconnections to
e.g. 1 (the parameter denotes the number of connections to be
served by a connection thread before
Dear Alex,
The good news is that it bloats only on one server,
so the problem must on that configuration.
There were a couple of memory leaks reported for postgres 7.4,
not sure if these hit you (google around):
http://www.postgresql.org/docs/7.4/static/release-6-5.html
do you have a chance to
Hello Gustaf,
Thanks for the suggestions - I will try upgrading to Postgres 8.2.
As to the script, there was a problem with install-aol, and install
seem to work ok.
However I resolved that issue - will update the script.
Is there any good and clear documentation for the options available in
Tom, Gustaf, All
Yes, that happens even if the same page is requested.
Could you tell me more about pre-queue filters?
The interesting thing is that I only see this memory leak issue on one
of my servers.
All servers run x86 Debian, though might be slightly differently
dist-upgraded, Postgres
Can you narrow down what code actually runs on this one page? If it happens on
any one page, is there some shared code?
It is very likely, which would be lucky for you, that some large data
structure is being created with each request and not deleted. As Gustaf said,
I guess that XOTcl
John Buckman wrote:
On Fri, Feb 29, 2008 at 05:41:44PM +0100, Juan Jos? del R?o [Simple
Option] wrote:
In my case I run AOLServer with customized code on top of it. No
OpenACS. No modules except nspostgres. In 32 bits it works like a charm.
No memory leaks. It simply works (damn fast!).
Hm,
The key, it seems to me, is that the memory footprint stablizes over time in a
real world situation. A memory leak is best proven by watching memory grow
while visiting a limited set of pages, essentially a stable load. Visiting a
single page (with the same result) over and over should not
On 2008.02.29, Alex [EMAIL PROTECTED] wrote:
What would be a normal size of 32 bit nsd process? How can it be
reduced? One of my servers only has 1G or ram, and I am forced to
restart nsd every so often, when it uses up almost all the memory.
Running 4.5 + XoTCL + tcllib, it seams to grow up
