Alfresco community 3.4.d - heap dominated by xml and xssf

[nicholasdipiazz]

Hello everyone,

We are running alfresco community 3.4.d.

We seem to be experiencing a memory leak relating to XSSF classes. After running for a long time, Alfresco starts throwing OutOfMemoryException: GC overhead limit exceeded.

There is a huge amount of data in org.apache.xmlbeans classes. Those classes seemed to be used within org.apache.poi.xssf related classes.

So XSSF seems to be the culprit. Does anyone know why our Alfresco is holding onto so much XSSF data? Is this a known memory leak that anyone has ever ran into?

And the org.apache.poi references are held by org.openxmlformats.schemas.spreadsheetml

Here is a look at the top of the histogram:

Class Name                                                            |   Objects |  Shallow Heap | Retained Heap
——————————————————————————————————————
org.apache.xmlbeans.impl.store.Xobj$AttrXobj                          | 7,358,505 | 1,177,360,800 |              
org.apache.xmlbeans.impl.store.Xobj$ElementXobj                       | 3,156,633 |   530,314,344 |              
char[]                                                                | 2,004,985 |   275,686,240 |              
byte[]                                                                |    48,153 |   174,314,464 |              
java.util.TreeMap$Entry                                               | 1,412,889 |    90,424,896 |              
java.lang.String                                                      | 2,069,690 |    82,787,600 |              
java.lang.Object[]                                                    |   874,520 |    53,356,696 |              
org.apache.poi.xssf.usermodel.XSSFCell                                |   931,492 |    52,163,552 |              
java.util.HashMap$Entry[]                                             |   316,792 |    50,854,920 |              
org.openxmlformats.schemas.spreadsheetml.x2006.main.impl.STCellRefImpl|   931,492 |    44,711,616 |              
——————————————————————————————————————
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Dominator tree:

Class Name                                                                                       | Shallow Heap | Retained Heap | Percentage
———————————————————————————————————————————————
org.quartz.simpl.SimpleThreadPool$WorkerThread @ 0x2aab1391ce10  DefaultScheduler_Worker-4 Thread|          200 | 2,301,327,064 |     77.94%
org.apache.catalina.session.StandardManager @ 0x2aab125446f8                                     |          224 |   114,470,184 |      3.88%
org.apache.catalina.loader.WebappClassLoader @ 0x2aab1242b3b8                                    |          312 |    55,878,576 |      1.89%
net.sf.ehcache.Cache @ 0x2aab12f5fe68                                                            |          184 |    21,150,600 |      0.72%
net.sf.ehcache.Cache @ 0x2aab12f68c40                                                            |          184 |    20,080,392 |      0.68%
org.springframework.beans.factory.support.DefaultListableBeanFactory @ 0x2aab126dd7f0            |          368 |    18,612,592 |      0.63%
class org.springframework.beans.CachedIntrospectionResults @ 0x2aabf452cea0                      |           24 |    11,356,368 |      0.38%
class org.apache.pdfbox.pdmodel.font.PDFont @ 0x2aabf6498778                                     |           48 |    10,681,464 |      0.36%
org.apache.lucene.index.SegmentReader @ 0x2aab6c873400                                           |          240 |     9,727,080 |      0.33%
org.apache.lucene.store.RAMFile @ 0x2aab6597abf0                                                 |           56 |     9,500,984 |      0.32%
net.sf.ehcache.Cache @ 0x2aab12f6b5f8                                                            |          184 |     8,887,560 |      0.30%
org.apache.lucene.index.IndexWriter @ 0x2aab20aadbd0                                             |          280 |     8,741,040 |      0.30%
net.sf.ehcache.Cache @ 0x2aab12f71a00                                                            |          184 |     8,626,408 |      0.29%
org.apache.lucene.store.RAMFile @ 0x2aabae01b488                                                 |           56 |     8,028,992 |      0.27%
org.hibernate.impl.SessionFactoryImpl @ 0x2aab138c8468                                           |          248 |     6,202,544 |      0.21%
class org.apache.cxf.jaxb.JAXBDataBinding @ 0x2aabf6ea67a0                                       |           72 |     5,587,992 |      0.19%
———————————————————————————————————————————————

‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Leak suspects report:

Problem Suspect 1

The thread org.quartz.simpl.SimpleThreadPool$WorkerThread @ 0x2aab1391ce10 DefaultScheduler_Worker-4 keeps local variables with total size 2,301,327,064 (77.94%) bytes.

The memory is accumulated in one instance of "org.quartz.simpl.SimpleThreadPool$WorkerThread" loaded by "org.apache.catalina.loader.WebappClassLoader @ 0x2aab1242b3b8".

Keywords
org.apache.catalina.loader.WebappClassLoader @ 0x2aab1242b3b8
org.quartz.simpl.SimpleThreadPool$WorkerThread

[nicholasdipiazz]

When we made the following change…

###################################### 
### Force Indexing to Background #### 
###################################### 
index.tracking.disableInTransactionIndexing=true 
lucene.maxAtomicTransformationTime=0 ‍‍‍‍‍

the problem with the memory leak went away, but then Lucene indexing stopped functioning.

This makes us believe the Lucene index is the real reason behind this memory leak. I found some forums suggesting there are problems in the earlier versions of alfresco 3 but 3.4d was supposed to have them fixed.

But isn't that strange? Because normally a Lucene memory leak would show a huge quantity of org.apache.lucene.* in the Heap. But as you see from my heap analysis from MAT, that is not the case! HELP!!

[mp1smw]

Did you manage to find a solution to this problem?
We are having a similar issue and can not figure out how to resolve it. Out of desperation I am thinking about just upgrading to the latest version but that is likely to cause more problems than it solves so if you did find a fix I would really appreciate you posting it.
Thanks