Question
Java process for method server exceeds limit during large search
All,
We have been experiencing seemingly random runaway Java processes on our Windchill system over the last few weeks and are trying to determine a root cause and preventative measures. At this point, we have been able to force what appears to be a similar situation by running searches that result in very large result sets. (Though we question the likelihood of user searches actually being the historical cause...)
For example, if we run a basic search for EPMdocs using a keyword like *.asm, it returns the first 15 of 36,124 assembly objects in our system in about 25 seconds (no FAST indexed search) and the rest of the system is fine. BUT, if we click on "Full List" (an admittedly bad idea) the memory consumption of one methodserver Java process quickly jumps past its maxheap setting and proceeds to slowdown the entire WC system. (We have 2 methodservers and 1 background methodserver incidentally.) It then takes 15 minutes or more for the process to recover (if at all) and in most cases we have to kill the process or restart the system.
PTC's recommendations so far have been focused on using query limits to reduce any possible burden on the JVMs. But this has the undesirable consequence of yielding an error message (and no results at all) whenever a search exceeds this arbitrary limit - surely a frustrating user experience. A much more palatable and less Draconian measure would be to simply tell users "don't click on Full List" and leave the limits reasonably high.
And while this all addresses search issues very directly, we can't help but wonder if it fully addresses the issue of the runaway JVM.
So now to the questions. Have you seen such behavior from your method servers and how did you resolve it? (properties, added methodservers, etc.) Does search create a similar burden in your system and how have you addressed it? (query limits, user training, etc.)
Thanks,
John Frankovich
GSI Group LLC
www.gsiag.com<">http://www.gsiag.com>
We have been experiencing seemingly random runaway Java processes on our Windchill system over the last few weeks and are trying to determine a root cause and preventative measures. At this point, we have been able to force what appears to be a similar situation by running searches that result in very large result sets. (Though we question the likelihood of user searches actually being the historical cause...)
For example, if we run a basic search for EPMdocs using a keyword like *.asm, it returns the first 15 of 36,124 assembly objects in our system in about 25 seconds (no FAST indexed search) and the rest of the system is fine. BUT, if we click on "Full List" (an admittedly bad idea) the memory consumption of one methodserver Java process quickly jumps past its maxheap setting and proceeds to slowdown the entire WC system. (We have 2 methodservers and 1 background methodserver incidentally.) It then takes 15 minutes or more for the process to recover (if at all) and in most cases we have to kill the process or restart the system.
PTC's recommendations so far have been focused on using query limits to reduce any possible burden on the JVMs. But this has the undesirable consequence of yielding an error message (and no results at all) whenever a search exceeds this arbitrary limit - surely a frustrating user experience. A much more palatable and less Draconian measure would be to simply tell users "don't click on Full List" and leave the limits reasonably high.
And while this all addresses search issues very directly, we can't help but wonder if it fully addresses the issue of the runaway JVM.
So now to the questions. Have you seen such behavior from your method servers and how did you resolve it? (properties, added methodservers, etc.) Does search create a similar burden in your system and how have you addressed it? (query limits, user training, etc.)
Thanks,
John Frankovich
GSI Group LLC
www.gsiag.com<">http://www.gsiag.com>