have you turned on codecahe , if that is true can you monitor codecahe? known issue with codecache in java 7, when codecache fills up the compiler may not get get restarted even after the codecache occupancy drops down to half after the emergency flushing, this may cause high cpu usage by the compiler threads. if above all true here are the solutions. 1. increase codecache may be 128MB 2. upgrade jdk to 8
On Tue, Feb 11, 2020 at 7:40 PM James H. H. Lampert < jam...@touchtonecorp.com> wrote: > Ladies and Gentlemen: > > We have a customer installation in which the JVM job for our Tomcat > server is frequently using massive amounts of CPU. > > It's Tomcat 7.0.67, running on an AS/400, in a 64-bit Java 7 JVM, with > -Xms3096m and -Xmx5120m JVM arguments. > > GC information on the JVM job shows: > > Garbage collected heap: > > Initial heap size . . . . . . . . . : 3096.000M > > Maximum heap size . . . . . . . . . : 5120.000M > > Current heap size . . . . . . . . . : 4458.562M > > Heap in use . . . . . . . . . . . . : 1907.673M > > Other memory: > > Internal (break) memory size . . . . : 504.982M > > JIT memory size . . . . . . . . . . : 74.000M > > Shared classes memory size . . . . . : 0.000M > > General GC information: > > Current GC cycle . . . . . . . . . . : 2184 > > GC policy type . . . . . . . . . . . : GENCON > > Current GC cycle time . . . . . . . : 552 > > Accumulated GC time . . . . . . . . : 5108241 > > It seems to be doing a lot of garbage-collecting. > > Would switching to Java 8 help? Would switching to 7.0.93 help? > > -- > James H. H. Lampert > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- *Thanks* *Niranjan*
