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-TraceClassLoading-TraceClassUnloading.txt -- Niels http://nielsmayer.com _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
