You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xindice-users@xml.apache.org by "W. Peschke" <Wo...@gmx.ch> on 2002/03/14 23:01:29 UTC

Memory problems under linux

Hi,

we are coding an application based on xindice as database and tomcat as
webserver.

Since we are not the only participants on the server, we are forced to
configure tomcat cooperating with apache.

On a linux system (256MB) Ram, we run Apache, PHP, Tomcat 3.3 (because
there is no module for 4.0 and apache yet) and Xindice RC2.
The Java VM (1.4) handling tomcat and xindice starts with 27 MB ram but
increases rapidely up to >100 MB, where we get at the limit of the
server, which starts to cache from this point.
We tried to reduce the max. heap of the VM, but it didn't solve the
problem.

Running the whole system in a windows environment, we aren't confronted
with any problems.

Does anyone of you have similar experiences and maybe an idea, how to
reduce the exhaustive memory use of tomcat and xindice? Maybe to start
the garbage collection of java manually or something like that, because
I don't have the impression, that all the allocated memory is really
needed.


Thanks for any ideas,
W. Peschke



Re: Memory problems under linux

Posted by Anders Conrad <ac...@dsl.dk>.
Hi,

we are seing similar problems. I have no solution, but maybe we can come closer by exchanging info. We are acessing Xindice through Tomcat/Apache, running the Cocoon servlet. Xindice queries are performed through the java interface, encoded into Cocoon XSP pages, which transform to java classes. Each page lookup from a broser client results in two Xindice queries, the results being correctly included in the page sent to the browser. A continuous flow of requests will result in an the number of tomcat and xindice processes growing continuously, until memory has been used up or no more processes are available.

It could seem like a simple cleanup problem in my code. But I use exactly the same java code to access xindice as in standalone programs, always including col.close() in the finally section. 
I have also tried to fiddle with Tomcat parameters like session-timeout, the VM heap size, as well as experimenting with limiting max_threads and max_spare_threads. Nothing makes any change. Similar symptoms have been reported on the tomcat mailing list and I doubt we can do anything about it with tomcat version 3.x.

What struck me is, that there is a little bit CPU activity on the xindice processes, long after the results from Xindice have been delivered to the client and the resources should have been freed. This behaviour is different that from a standalone version of the same query. This might be a clue to the issue, if anyone has any insight into what activity might be in a xindice thread, even after the col.close() call. Or does tomcat not destroy the object until after the timeout? I am mystified!

Anders

----- Original Message ----- 
From: "W. Peschke" <Wo...@gmx.ch>
To: <xi...@xml.apache.org>
Sent: Thursday, March 14, 2002 11:01 PM
Subject: Memory problems under linux


> Hi,
> 
> we are coding an application based on xindice as database and tomcat as
> webserver.
> 
> Since we are not the only participants on the server, we are forced to
> configure tomcat cooperating with apache.
> 
> On a linux system (256MB) Ram, we run Apache, PHP, Tomcat 3.3 (because
> there is no module for 4.0 and apache yet) and Xindice RC2.
> The Java VM (1.4) handling tomcat and xindice starts with 27 MB ram but
> increases rapidely up to >100 MB, where we get at the limit of the
> server, which starts to cache from this point.
> We tried to reduce the max. heap of the VM, but it didn't solve the
> problem.
> 
> Running the whole system in a windows environment, we aren't confronted
> with any problems.
> 
> Does anyone of you have similar experiences and maybe an idea, how to
> reduce the exhaustive memory use of tomcat and xindice? Maybe to start
> the garbage collection of java manually or something like that, because
> I don't have the impression, that all the allocated memory is really
> needed.
> 
> 
> Thanks for any ideas,
> W. Peschke
> 
>