On Tue, Oct 13, 2009 at 10:03 AM, Vincent Massol <[email protected]> wrote:
... * After deletion of 1.1MB attachment: used memory from 98MB to 132MB !! But still within the 155MB allocated heap memory ... * After adding a 7.3MB attachment: heap memory max from 155 to 261 (=>110MB!) * After removing it, need 297MB heap (even more)
I think a good fix for this would be to turn off attachment versioning and recycle-bin by default. In http://lists.xwiki.org/pipermail/users/2009-March/015435.html and http://www.mail-archive.com/[email protected]/msg07136.html I suggest using: #-# Whether the attachment recycle bin feature is activated or not storage.attachment.recyclebin=0 #-# Whether the attachment versioning feature is activated or not xwiki.store.attachment.versioning=0 #-# Whether the attachments should also be rolled back when a document is reverted. xwiki.store.rollbackattachmentwithdocuments=0 Another suggestion:
some kind of heuristic could be employed, as the default, e.g. the recylcle-bin is used to hold deleted attachments, except when the attachments exceed a certain size, say 1Mb. In that case the user is warned of permanent deletion and can "ok" it away.
Finally, http://www.mail-archive.com/[email protected]/msg10311.html has some additional info re jython, classloading, etc: http://blog.headius.com/2009/01/my-favorite-hotspot-jvm-flags.html
-XX:OnOutOfMemoryError="mail -s 'OOM on `hostname` at `date`' [email protected] <<< ''" as a way to send out email when there's an OutOfMemoryError. Poor-man's monitoring!
-XX:+HeapDumpOnOutOfMemoryError -XX:+PrintCompilation prints out the name of each Java method Hotspot
decides to JIT compile. The list will usually show a bunch of core Java class methods initially, and then turn to methods in your application. In JRuby, it eventually starts to show Ruby methods as well.
-XX:+PrintGCDetails includes the data from -verbose:gc but also adds
information about the size of the new generation and more accurate timings.
-XX:+TraceClassLoading and -XX:+TraceClassUnloading print information class
loads and unloads. Useful for investigating if you have a class leak or if old classes (like JITed Ruby methods in JRuby) are getting collected or not.
Trying this out on Xwiki 2.0M2 gives some interesting, voluminous results: http://nielsmayer.com/xwiki-catalina-with-PrintGCDetails-PrintCompilation-Tr... -- Niels http://nielsmayer.com