Prev: ECLIPSE - slow deployment with WAS 6.0
Next: Using browser's proxy-settings from a javaws-app?
From: Kevin McMurtrie on 29 Jan 2010 02:16
In article
<2e4e3224-d0a3-4f73-af25-9c17600a3259(a)g29g2000yqe.googlegroups.com>,
Sherkan <grzekuk(a)gmail.com> wrote:

> -XX:CompileThreshold=100

To my knowledge, there is no version of Java 1.5 that is free of serious
HotSpot bugs. Setting the compilation threshold so low almost
guarantees that it's going to crash or unroll loops incorrectly.

Java 1.6 seems better (so far) but I still wouldn't set the compilation
threshold lower than 10000 for a server. With a value of 100, your 512MB
Perm Heap may be completely consumed during initialization, leaving your
main code paths interpreted.
--
I won't see Google Groups replies because I must filter them as spam
From: Sherkan on 29 Jan 2010 11:40
Hello guys,
Thank you for reply for my email.
I need to explain one think.
I got 3 apps on tomcat 6, based on:

first and second: Seam 2.0.1GA, Facelets, JSF, RichFaces, jdbc
third is on Seam 2.2.0GA, facelets, JSF, Richfaces, jdbc

All app jar libs are in each app WEB-INF/lib directory.
One month ago my first and second apps worked alone withouth third, on
newest centos 64bit, Core 2 Duo 3GHz, 4 gb ram, and postgres 8.3,
I had to change datacenter and it all works right now, on newest 32bit
centos on Quad Core 2,5Ghz and 8GB ram.
Don't ask me why not 64bit (this is long story) :(

The first time my apps worked on this configuration for over 2 years.
Server worked fine for months without rebooting. Right now on the same
configuration, same tomcat, same postgres and even driver this f***
server can't hold 2 days.
It crash randomly, 20minutes after start, 5 hours, 10 hours. I even
don't know what crashes my whole server so randomly.

Yesterday I loose whole day to profile my all apps, with yourkit
profiler, and it all looks fine without memory leaks, and also if
there could be memory leak, why server crash 20 minutes after start,
there could be huge leak, but it should get an error message like:
java heap space or perm gen space, not this one.

OK here are my changes:
1. I have checked it there is no new libraries of seam, jdbc etc.
2. I've changed JSF state in web.xml from server in all aps to client.
3. I've raised -XX:NewSize=512m -XX:MaxNewSize=512m"
from 256 to 512 and I see little difference.
Today server works for all day without problems, and I see in jvm
logs, my machine start FULL GC...

68504.347: [Full GC 68504.347: [ParNew: 1334K->24K(471872K), 0.0056640
secs] 215448K->214137K(996160K), 0.0058180 secs]

In previous logs I couldn't find such an FULL GC log.
but there is also new problem, why I get this FULL gc log sometimes?

72356.821: [Full GC 72356.821: [ParNew: 419456K->419456K(471872K),
0.0000080 secs] 634061K->634061K(996160K), 0.0000940 secs]
GC locker: Trying a full collection because scavenge failed
72356.821: [Full GC 72356.821: [Tenured: 214604K->217917K(524288K),
0.7640090 secs] 634061K->217917K(996160K), [Perm : 69328K->69328K
(262144K)], 0.7641500 secs]


Here are my complete server parameters:
JAVA_OPTS="$JAVA_OPTS -server -Xms1024m -Xmx1024m -XX:PermSize=256m -
XX:MaxPermSize=512m"
JAVA_OPTS="$JAVA_OPTS -XX:MinHeapFreeRatio=40 -
XX:MaxHeapFreeRatio=70"
JAVA_OPTS="$JAVA_OPTS -XX:NewRatio=3 -XX:NewSize=512m -
XX:MaxNewSize=512m"
JAVA_OPTS="$JAVA_OPTS -Dsun.rmi.dgc.server.gcInterval=3600000"
JAVA_OPTS="$JAVA_OPTS -XX:+UseParNewGC -XX:
+CMSPermGenSweepingEnabled"
JAVA_OPTS="$JAVA_OPTS -XX:+ClassUnloading -XX:
+CMSClassUnloadingEnabled -XX:CompileThreshold=100"
JAVA_OPTS="$JAVA_OPTS -XX:+PrintGCDetails -verbose:gc -Xloggc:/
serwer/jvm"
JAVA_OPTS="$JAVA_OPTS -Djava.net.preferIPv4Stack=true"

Yes there was twice compile. I set this to 100 because I found on one
web site author offer this to set to minimum to force to compile to
native code very fast classes.

JAVA_OPTS="$JAVA_OPTS -XX:+PrintGCDetails -verbose:gc -Xloggc:/
serwer/jvm"

/serwer/jvm - this is my centos jvm.log file path for gc logs.
OK i will remove compilethreeshold in the next time, and we so how it
works.
I hope all java opts don't break next time.
From: jolz on 29 Jan 2010 18:26
> If the problem were a memory leak or insufficient memory allocated to
> the heap, you wouldn't get a SIGSEGV.

If memory leaks in native code malloc will eventually return NULL (or
more likely bad_alloc will be thrown). In 32 bit system it may be really
fast, especially if Xmx is set to maximum possible value. Sun's JVM and
JRockit and possibly all other JVM ignore malloc failures and will
crash. So yes, memory leak may cause SIGSEGV.
From: jolz on 29 Jan 2010 18:30
> It crash randomly, 20minutes after start, 5 hours, 10 hours. I even
> don't know what crashes my whole server so randomly.

Are you sure it's a software problem? Very often faulty hardware
(possibly RAM) causes similar behaviour.
From: Sherkan on 30 Jan 2010 03:37
On 30 Sty, 00:30, jolz <BardzoTajneKo...(a)interia.pl> wrote:
> > It crash randomly, 20minutes after start, 5 hours, 10 hours. I even
> > don't know what crashes my whole server so randomly.
>
> Are you sure it's a software problem? Very often faulty hardware
> (possibly RAM) causes similar behaviour.

I really don't know:(
So why on 32bit system there will not be thrown exception java heap
space if there is memory leak instead of SIGSEGV?
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: ECLIPSE - slow deployment with WAS 6.0
Next: Using browser's proxy-settings from a javaws-app?