Hi Nikhil
We operate a similar architecture internally for our hprof analysis, with tools to automate the extract of heapdump, the analysis, and reporting views. I have made a number of modifications to Eclipse MAT that improve performance to make it suitable for use online.
1. How does cache work?
- Do you refer to the internal query cache or something else? If so, it simply caches the results of a query in memory.
2. Once Index files are generated, how much memory (RAM) do we need to see Leak suspect or dominator tree reports?
- In our deployment we turn off leak suspects view as it is too expensive for interactive and not many users use it.
- For dominator tree I have a number of patches. The main issue is it relies on the retained set size to do lookups. So, you might review my eclipse proposed bug
573908 which generates the retained set during indexing (quicker) and makes the dominator view open more quickly too.
( same as to generate Index files? ex: 70GB Hprof need 90GB RAM?)
- On our deployment we have a large host to generate most index files successfully. The opening and querying stages for JIFA require much less memory after the indexing is complete.
- Eclipse MAT engine is used underneath JIFA to perform the indexing stages. Generally speaking you need 1.2-2x (depending on heap layout) to successfully parse a heap with MAT.
- Some small
improvements are available that might help, and I have one
proposal here that is more complicated.
3. Can you please share rough high level Architecture for JIFA?
- There were some slides prepared earlier that may be useful, I do not have them.
Thanks!
Jason
