--- On Fri, 2/5/10, Carl <c...@etrak-plus.com> wrote: Carl,
> 1. The application runs fine on an older system. Do we have > the glibc and kernel versions for all systems? > > The old system: P4. 1GB memory, 1.3GB swap. > Uses swap on a regular basis. kernel is 2.4.25. > Java is 1.5.0_01-b08. Tomcat is 5.5.23. Glibc is > version 2.3..1. > > New systems: Server A (Dell T110) is a Xeon 3440, sever B > (Dell T105) is an AMD. A has 4GB memory and 19GB swap > which is never used. B has 6GB memory and 10GB swap > which is never used. A and B both use kernel version > 2.6.29.6, Java 1.6.0_18-b07 and Tomcat 6.0.24.. Glibc > version is 4.3.3 for both A and B. A couple of observations here: Both the old new kernels end in odd numbers. From memory, I thought the odd kernel numbers were experimental, while the even numbers were production or mainline. I don't remember when this numbering system took place, but certainly by the time the 2.6 kernels were released. From kernel.org, I didn't see a 2.6.29 release marked as stable. The thread implementation has changed between the 2.4 and 2.6 kernels. You can see the thread implementation change by running: getconf GNU_LIBPTHREAD_VERSION I'd be interested in knowing the result of that and getconf GNU_LIBC_VERSION on both systems, since I don't recognize 4.3.3 as a glibc version (latest stable is 2.11.1, so I'm assuming 2.4.3.3?). glibc has some thread bugs that were fixed, but not until 2.8 or 2.9. There was also a persistent bug for 32-bit systems that bites Java applications (not your concern since you're running 64-bit) that wasn't fixed until 2.10.1. So in short, I'm guessing this may be a glibc NPTL issue. There are some observations that don't match, in that you're using Java 6 (most problems are reported with Java 1.4 and Java 5), and that you've used OpenSuSE (kernel, glibc version?) with the same Tomcat failure. However: For some of the earlier 2.6 kernels, you could get around NPTL problems by setting this environment variable: export LD_ASSUME_KERNEL=2.4.1 which forces the use of the old linuxthreads model. I don't know if that option is available with the 2.6 kernel that you are using. Another work-around has been posted on the Java bugs forum, albeit for a different threading problem and Java 5: -XX:ParallelGCThreads=1 sets GC to single threads. It's not fixed in the Java bugs database, because later versions of RedHat Linux don't exhibit the SIGSEGV problem. Some people report that single-threading GC solves their problems, while other people report that it doesn't. Some things to try I guess: 1. export LD_ASSUME_KERNEL=2.4.1 (maybe in startup.sh?) if your kernel supports this.. 2. set -XX:ParallelGCThreads=1 in catalina.sh (JAVA_OPTS). This is an experimental switch, not documented here: http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp, but documented here: http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html 3. Move to an even-numbered kernel with a glibc of 2.10.1 or better. 2.10 might be OK for your environment since the bug fixed in 2.10.1 causes problems for 32-bit systems only. just my two cents . . . . /mde/ --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
