From: Kasemir, K. <kas...@or...> - 2016-10-11 17:24:28
|
Hi: ________________________________________ From: wil...@di... <wil...@di...> Attached is a screenshot from JVisualVM from when I have generated such an error, with -Xmx512m. Meanwhile, java is using 600% of my processor (I have eight hyperthreads). It is unclear to me what Java is doing. CS-Studio does not die, and I don't even get OutOfMemoryError from the Eclipse console, but this time I could kill CS-Studio with not too much difficulty. I can identify a screen that is gobbling about 200mb - this helps me generate such errors. -- I think until ~17:40, your screenshot shows the normal sawtooth-type memory usage pattern. JVM uses memory, brief GC runs frees it up, use, free, .. The GC runs are so brief that they don't actually show. Then, the used memory stays high, the GC runs all the time, but no memory is freed up. So the JVM does nothing but running GC, only to find that all memory is used, nothing to free up. If you have a screen that uses a lot of memory, would be good to know what in there is using the memory. I like JProfiler, it allows taking a memory snapshot and then compare the before/after set of object instances. But JProfiler is not free. In spite of all those heap dump tools, I don't understand why sometimes you run out of memory -> OutOfMemoryError, while at other times you're stuck in using all the CPU in CG. Maybe the high CPU usage keeps that code which would actually exhaust the memory from executing? I had a related issue with the scan server: It tries to delete past scans from memory when it uses 50% of its allotted memory. But instead of freeing memory, it was stuck in GC, using CPU. I fixed that by changing from deleting the oldest scan to replacing the complete oldest scan in memory with just basic info about the scan ID and status. For some reason, the JVM liked that better: It actually freed up memory without pegging the CPU load. -Kay |