You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@cocoon.apache.org by fr...@apache.org on 2002/03/17 14:44:52 UTC
cvs commit: xml-cocoon2/src/documentation/xdocs/userdocs/concepts storejanitor.xml
froehlich 02/03/17 05:44:52
Modified: src/documentation/xdocs/userdocs/concepts storejanitor.xml
Log:
more doc update
Revision Changes Path
1.4 +21 -23 xml-cocoon2/src/documentation/xdocs/userdocs/concepts/storejanitor.xml
Index: storejanitor.xml
===================================================================
RCS file: /home/cvs/xml-cocoon2/src/documentation/xdocs/userdocs/concepts/storejanitor.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- storejanitor.xml 5 Feb 2002 01:46:44 -0000 1.3
+++ storejanitor.xml 17 Mar 2002 13:44:52 -0000 1.4
@@ -11,20 +11,13 @@
<abstract>This document describes the usage of the StoreJanitor under Cocoon.</abstract>
</header>
<body>
- <s1 title="Goal"><p>This document describes the usage of the StoreJanitor under Apache Cocoon.</p></s1>
- <s1 title="Overview">
- <p>In the current design of Apache Cocoon there can be different stores for the different pipelines.
- For example you can choose a weaker store for the event pipelines (weaker=caches
- not many objects) and a "big" store for the stream pipelines. If you know which ones are more
- "cacheable", you can fine-tune your stores. This decision was made, because of the two pipeline objects.
- You can combine a non-caching-stream-pipeline with a caching-event-pipeline etc.</p>
- </s1>
- <s1 title="Implementation">
+ <s1 title="Goal"><p>This document describes the usage of the StoreJanitor under
+ Apache Cocoon.</p></s1>
+ <s1 title="Description">
<p>The implementation is quit simple! Every implementation of a Store can register in the
StoreJanitor. He checks in a configurable interval if memory is running low. If low,
- then the StoreJanitor first runs the GC. If Memory is still low, he greps via Round Robin
- a victim (Store) and frees xx% of all emlements in this Store. After that the StoreJanitor
- sleeps and waits for the next iteration.</p>
+ he greps via Round Robin a victim (Store) and frees xx% of all emlements in this Store.
+ After that the StoreJanitor sleeps and waits for the next iteration.</p>
</s1>
<s1 title="Configuration">
<source><![CDATA[
@@ -42,11 +35,11 @@
<s2 title="Example configuration">
<ul><li>Tomcat settings in tomcat.sh or tomcat.bat:</li></ul>
<source><![CDATA[
-%_RUNJAVA% %TOMCAT_OPTS% -Dtomcat.home="%TOMCAT_HOME%" -Xms100000000 \
+%_RUNJAVA% %TOMCAT_OPTS% -Dtomcat.home="%TOMCAT_HOME%" \
-Xmx200000000 org.apache.tomcat.startup.Tomcat %2 %3 %4 %5 %6 %7 %8 %9
]]></source>
<ul><li>StoreJanitor settings:</li></ul>
- <p>The freememory and heapsize paramter always depends on the Xms and Xmx
+ <p>The freememory and heapsize paramter always depends on the Xmx
parameter.</p>
<source><![CDATA[
<store-janitor
@@ -59,15 +52,20 @@
<parameter name="percent_to_free" value="10"/>
</store-janitor>
]]></source>
- <p>The <code>heapsize</code> _must_ be higher then the -Xms parameter and <code>freememory</code> _between_ those both. If you set
- the <code>heapsize</code> lower then the -Xms parameter and <code>freememory</code> very thin, then the cleanupthread
- will work all the time and cause a high system load. If you set the <code>heapsize</code> to close to the
- Xmx paramter and <code>freememory</code> to broad can cause a OutOfMemoryException. Somewhere in the middle
- is always the best.</p>
- <p> The <code>cleanupthreadinterval</code> defines the interval of the background thread which
- checks memory in seconds. Also this paramter should configured wisely. A to short interval can
- cause also a high system load. The <code>threadpriority</code> defines the priority of the
- background thread. 1 is lowest level and 10 the highest.</p>
+ <p>It is recommended to have <code>heapsize</code> equal to -Xmx, especially
+ on Sun's JVM which are unable to shrink its heap once it grows above minimum.
+ <code>freememory</code> should be greater than amount of memory necessary for normal
+ application operation.
+ </p>
+ <p> The <code>cleanupthreadinterval</code> defines the interval of the background
+ thread which checks memory in seconds. Also this paramter should configured wisely.
+ A to short interval can cause also a high system load. The
+ <code>threadpriority</code> defines the priority of the background thread.
+ 1 is lowest level and 10 the highest.</p>
+ <p>
+ The <code>percent_to_free</code> parameter describes, how much percent of the
+ elements of each registered Store shall be removed when low on memory.
+ </p>
</s2>
</s1>
</body>
----------------------------------------------------------------------
In case of troubles, e-mail: webmaster@xml.apache.org
To unsubscribe, e-mail: cocoon-cvs-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-cvs-help@xml.apache.org