Object creation, memory usage, and stuck threads

45 views
Skip to first unread message

Peter Matthew Eichman

unread,
Jul 18, 2017, 3:07:00 PM7/18/17
to fedor...@googlegroups.com
Hello all,

After we thought we had resolved our issues with hanging transactions and stuck threads on our dev server by increasing our ActiveMQ disk storage allocation [1], we have discovered that the issue has returned on our staging server.

This time, as far as we can tell, it is not the ActiveMQ resources getting used up that are causing the hanging (the disk space and memory usage percentages never went over 25% and 50%, respectively). We also increased the size of the ModeShape ring buffer from the default 1024 to 2048 [2]. Still, the system was hanging after anywhere from 100 to 300 transactions, where each transaction was creating (roughly) between 10-50 objects.

After enabling JMX remote monitoring on Tomcat, we had much more successful loads, and did not have any hanging transactions. However, things got progressively slower and slower over the 3 hour load. The slowdown happened in spurts, where any given request might take several seconds to complete, rather than less than a second as usual, which I believe corresponded to the JVM going through a GC cycle.

I'm attaching screenshots from the JMX monitoring of our CPU and memory usage. At a little ways into the load, the JVM started running at 100% CPU and spending about 20% of its time in garbage collection. And still the used memory in the heap kept growing.

My questions are:
1. How does this performance compare to expectations for Fedora?
2. What might be causing the gradual increase in memory that is unable to be freed by GC?
3. Has anyone else encountered stuck threads that mysteriously vanish once JMX is enabled?

Thanks,
-Peter

Configuration:
Oracle JDK 1.8u65
Tomcat 7.0.70
Fedora 4.7.0

JVM memory management params:
-XX:+UseConcMarkSweepGC
-XX:+CMSClassUnloadingEnabled
-XX:ConcGCThreads=5
-XX:MaxGCPauseMillis=200
-XX:ParallelGCThreads=20
-XX:MaxMetaspaceSize=512M
-Xms1024m
-Xmx2048m


--
Peter Eichman
Senior Software Developer
University of Maryland Libraries
fcrepostage-cpu-20170718.png
fcrepostage-heap-20170718.png

Peter Matthew Eichman

unread,
Jul 21, 2017, 1:22:33 PM7/21/17
to fedor...@googlegroups.com
Update on my investigation into this issue:

Examination of the heap dumps shows a problem area might be the org.fcrepo.event.serializer.JSONLDSerializer class. Its ObjectMapper looks like it is creating but then never releasing Jackson JSON serializer and deserializer objects. 1 of each is being created for each event. Each of those is about 1MB in size, and by the time of the last heap dump there were 228,300 of each of them, with a total memory usage of 456MB.

See attached screenshot taken from the Eclipse Memory Analyzer of the final heap dump.

-Peter
Screen Shot 2017-07-21 at 10.56.51 AM.png

Peter Matthew Eichman

unread,
Jul 21, 2017, 3:17:21 PM7/21/17
to fedor...@googlegroups.com
Ticket created for this issue: https://jira.duraspace.org/browse/FCREPO-2540
Reply all
Reply to author
Forward
0 new messages