It doesn't sound like you are reporting any java errors like being unable to create a new thread or being unable to allocate more memory.
But just in case:
Your max heap size is set to 3072M.
What is the value of the Environment variable: "LDR_CNTRL"
There is a table on this web page:
"Table 2. Default LDR_CNTRL settings for different heap sizes"
http://www.ibm.com/developerworks/library/j-nativememory-aix/
The table shows that if you have LDR_CNTRL set to 'MAXDATA=0XA0000000@DSA', then you will only be able to allocate a max of Xmx2304M.
Based on the setting of "LDR_CNTRL", If the process ever tries to allocate more heap storage than 2304, then there is a chance your heap is pointing to unreachable memory.
Chris Hiebert
Senior Programmer/Analyst
Disclaimer: Any views or opinions presented are solely those of the author and do not necessarily represent those of the company.
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of James H. H. Lampert
Sent: Friday, February 3, 2017 9:56 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: More, Re: Got a weird suggestion about a troublesome Tomcat installation running in a subsystem
Ok. We've established that getting rid of the private pool appears to have no effect on Tomcat performance (or BIRT performance within our webapp context in Tomcat).
And we've established that the "problem" box is a Power 7 with 16G memory in 4 4G main storage cards, the "lighing fast" box is a Power 8 with 32G in 2 16G main storage cards, and our own production box is no more than a Power 6, with 8G in 2 4G cards.
They're all running Tomcat 7 under 32-bit Java 6:
The "problem" box is an E4C with 2 LPARs, running V7R1, with Tomcat
7.0.67 running under jvmap3260sr16fp35-20161024_04.
The "lightning fast" box is a 41A with 1 LPAR, running V7R1, with Tomcat
7.0.62 running under jvmap3260sr16fp35-20161024_04.
Our own production box (which wasn't quite as fast on our quickie benchmark BIRT report as we'd initially thought) is an E4A with 1 LPAR, running V6R1, with Tomcat 7.0.67 running under jvmap3260sr9-20101130
All three have QPRCMLTTSK set to 2.
The JVM arguments (at least the ones that appear even vaguely relevant) showing up for the Tomcat's JVM job on the "problem" box are:
-Dos400.awt.native=true
-Djava.awt.headless=true
-Djava.version=1.6
-Xms2048m
-Xmx3072m
-XX:PermSize=256m
-XX:MaxPermSize=256m
-Djavax.servlet.request.encoding=UTF-8
-Dfile.encoding=UTF-8
The GC information page shows:
Garbage collected heap:
Initial heap size . . . . . . . . . : 2048.000M
Maximum heap size . . . . . . . . . : 3072.000M
Current heap size . . . . . . . . . : 2048.000M
Heap in use . . . . . . . . . . . . : 816.366M
Other memory:
Internal (break) memory size . . . . : 202.883M
JIT memory size . . . . . . . . . . : 24.000M
Shared classes memory size . . . . . : 0.000M
If a fairly complex BIRT report (more complex than the "quickie benchmark" report, requiring around 25 seconds) is run, heap in use climbs to 1025.517M, and 1206.761M if it is then refreshed.
--
JHHL
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
http://amzn.to/2dEadiD
midrange.com
