> From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Subject: Re: Performance issue 8.5.20 (metaspace related?) > > > That sounds like a healthy behavior to me. That means GC is > > > occurring and Metaspace is getting cleaned up. Why do you think > > > Metaspace is the problem?
> > Because I can observe that when the metaspace is collected the > > requests become fast. I observer that a few hours ago, looking at > > the metaspace graph of the java console and doing requests just > > after the collect. > RMI is known for flagrantly wasting permgen/metaspace because of all > the Proxy objects and special throw-away Class objects it uses, etc. > But I'm not sure why the metaspace filling up would have such a > dramatic effect on performance. > At any rate, this is not a problem with Tomcat itself: this is likely > entirely JVM-related. Is it possible that the system is getting into swapping? The heap has been set to 20 GiB, but I didn't see any mention of how much actual memory the system has. Do you really need a 20 GiB heap? Sometimes smaller is better. Might also want to try turning off UseHugeTLBFS. I wonder if there are heap objects tied up due to dead but not collected metaspace items; when metaspace is GC'd, the heap usage might well shrink also. (This might be a G1GC bug, but that seems unlikely.) Perhaps the RMI mechanism (which I haven't looked at in many years) is searching an ever-growing set of soft/weak references that are removed when metaspace is collected. A smaller heap might help there. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
smime.p7s
Description: S/MIME cryptographic signature
