On 2 Dec 2013 at 10:26:33, [email protected] ([email protected](mailto://[email protected])) wrote: [snip]
1 - Document Cache Analysis =======================
* There are 3552 XWikiDocument in memory for 195MB * The document cache size is 2000 on xwiki.org * Large documents (such as Test Reports) take 6MB each (XDOM caching) * So if we had only large documents in the wiki the cache would need 2000*6MB = 12TO * I don’t think this cache is memory aware, meaning it doesn’t free its entries when memory is low * 178MB for 2000 docs means average of 89K per document. Huge variation between docs with big content and docs with no or small content
This means that when memory is low on xwiki.org it should be enough to call a few pages with some large content to get an OOM.
4 ideas to explore:
[snip]
I believe optimizing the XDOM memory footage is the only real solution but we’ve already done a first pass on that and I don’t know much more we can win. We should still have a second look and be creative ;)
For example, I’m sure we can find better ways for storing SpaceBlock, SymbolBlock, etc.
FTR: * SpaceBlock (710035 instances): 22MB * SpecialSymbolBlock (371857 instances): 14MB * WordBlock (796535 instances): 79MB * NewLinesBlock (25640): 820K For example for storing just the letter “y” in a WordBlock, it takes 624 bytes vs 56 bytes for the “y” in a String. That’s because for we have parent refs, previous/next sibling refs, children blocks, param blocks to save too. Said differently, our current XDOM structure is not made to be memory efficient. [snip] Thanks -Vincent PS: The reason we use different instances for SpaceBlock and SpecialSymbolBlock ATM: /** * A new line block. Note that we don't make NewLineBlock a singleton since that would cause problems when using * Block APIs to manipulate a tree of blocks (for example to find the position of a new line block in a list using * {@link java.util.List#indexOf(Object)} wich would always return the first new line block). * @since 2.6RC1 */