//
One correction, option -XX:-HeapDumpOnOutOfMemoryError disables heapdumps on
OOM, you should use -XX:+HeapDumpOnOutOfMemoryError - with plus sign, to enable
it.
//
Thanks for the follow-up.
--Eric
2015-03-21 12:37 GMT+02:00 Антон Мацюк :
> 2015-03-21 2:06 GMT+02:00 Eric Robinson :
>>> Set this options to JVM, and it will make heapdumps automatically.
>> Will these heap dumps be the same size as the current tomcat memory
>> utilization?
> Yeap, and OOM will guarantee that there is no garbage
2015-03-21 2:06 GMT+02:00 Eric Robinson :
>> I think if you have vendor-locked app in vendor-locked environment (am I
>> right?)
> Yes indeed.
So, worth a try, at least.
>> Set this options to JVM, and it will make heapdumps automatically.
> Will these heap dumps be the same size as the current
//
I think if you have vendor-locked app in vendor-locked environment (am I
right?)
//
Yes indeed.
//
As I said above, there is an options for JVM:
-XX:-HeapDumpOnOutOfMemoryError - it will make heapdump on OOM.
-XX:HeapDumpPath=./java_pid.hprof - give it an reasonable path to file.
Set this o
2015-03-20 22:29 GMT+02:00 Eric Robinson :
>> Very good information. I much prefer finding the actual root causes of
>> things rather than just bumping the memory, but I'm not sure how much that
>> would help because the best I can do is report the issue to the vendor.
>> Changing the code is of
//
Mostly leaner - a 32-bit JVM uses 32-bit pointers, so object references consume
less heap and stack space. Whether or not the code runs faster or slower
depends on what you're doing, since the tradeoff is fewer registers available
in 32-bit mode, which can lead to more register spills and re
//
You can look for biggest objects in heap (using MAT, Leak Suspects report,
Dominators Tree report).
This way you can try to find what was the exact reason of OOM instead of just
thinking "eh, I need to give instances more memory".
MAT does things good. I've already found using MAT+JVVM the rea
> From: Eric Robinson [mailto:eric.robin...@psmnv.com]
> Subject: RE: Java Heap Space / Thread Dump Numbers
> > If you have the option, you might want to run a 32-bit JVM; it will
> > probably run leaner
> > and faster than a 64-bit JVM will.
> What do you mean my
2015-03-20 22:09 GMT+02:00 Eric Robinson :
>> I've posted above some howtos, have you looked at them?
> No, I'm not sure how useful I would find them. I think the heap summary is
> probably all I need, but I may be wrong. Would the heap dump provide more
> actionable intel as far as tuning my me
> From: Eric Robinson [mailto:eric.robin...@psmnv.com]
> Subject: RE: Java Heap Space / Thread Dump Numbers
> Would the heap dump provide more actionable intel as far as tuning my memory
> parameters?
It would provide information about what types of objects are consuming the heap
//
Recent 64-bit JVMs will automatically use "-XX:+UseCompressedOops".
I'm not sure about your version, specifically. If you have the option, you
might want to run a 32-bit JVM; it will probably run leaner and faster than a
64-bit JVM will.
//
Interesting. What do you mean my faster and leaner?
//
Yeah, heapdumps.
I've posted above some howtos, have you looked at them?
//
No, I'm not sure how useful I would find them. I think the heap summary is
probably all I need, but I may be wrong. Would the heap dump provide more
actionable intel as far as tuning my memory parameters?
--Eric
2015-03-20 1:15 GMT+02:00 Eric Robinson :
> Heap dumps?
> What we do is called a thread dump, as far as I know. We use kill -3 on
> Linux, which dumps the thread activity. The memory data shows up at the
> bottom of that. See:
> http://producthelp.sdl.com/WorldServer/10.2/en/GUID-4F09CD10-BC4F-4
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Eric,
On 3/19/15 7:15 PM, Eric Robinson wrote:
> Christopher Shultz wrote: // Time to upgrade. Tomcat is hideously
> out of date (probably because you are using RedHat's Tomcat
> package), at least by version number. I'm not sure what RedHat
> doe
Christopher Shultz wrote:
//
Time to upgrade. Tomcat is hideously out of date (probably because you are
using RedHat's Tomcat package), at least by version number. I'm not sure what
RedHat does (if anything) about security fixes, etc. but a vanilla 6.0.18 is
probably vulnerable and has been for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Eric,
On 3/19/15 11:15 AM, Eric Robinson wrote:
> Thanks for the feedback. We run various versions of RHEL (5.5 to
> 6.3) x64. Tomcat is mostly 6.0.18. Java is mostly 6u21 x 64.
Time to upgrade. Tomcat is hideously out of date (probably because yo
> PSYoungGen total 95808K, used 22323K [0x2aaac377,
> 0x2aaaca21, 0x2aaaca21)
> eden space 82432K, 10% used
> [0x2aaac377,0x2aaac402f7f8,0x2aaac87f)
> from space 13376K, 99% used
> [0x2aaac87f,0x2aaac94fd5a8,0x2aaac950)
>
Eric, if you are looking for a reasons and think, what can be done
with OOMs, take a look at this page:
http://www.oracle.com/technetwork/articles/java/vmoptions-jsp-140102.html
There is an options:
-XX:-HeapDumpOnOutOfMemoryError - it will make heapdump on OOM.
-XX:HeapDumpPath=./java_pid.hprof -
> From: Eric Robinson [mailto:eric.robin...@psmnv.com]
> Subject: Java Heap Space / Thread Dump Numbers
> PSYoungGen total 95808K, used 22323K [0x2aaac377,
> 0x2aaaca21, 0x2aaaca21)
> eden space 82432K, 10% used
> [0x2aaac377,0x2aaac402f7f8,0x2aaac
19 matches
Mail list logo
