![[HaBo]](/styles/default/logoklein.png){kind=small}
bitmuncher
Senior-Nerd
Ich bin gerade dabei ein paar Tomcats in OpenVZ-VMs auszulagern. Das stellt auch soweit kein Problem dar, solange diese quasi mit Default-Libraries arbeiten. Da ich aber zum Senken der BusyThreads den AJP-Connector mit tomcat-native verwenden will, müssen ein paar zusätzliche Bibliotheken geladen werden. Das funktioniert solange es nicht innerhalb einer VM ist. Sobald diese Bibliotheken im System verfügbar gemacht werden, kommt es zum Crash des Tomcats schon beim Hochfahren, bevor überhaupt die Webapp angesprochen wird. Laut hs_err-Log wird ein SIGSEGV, also ein Segmentation Fault ausgelöst. Einen Fehler in der Webapp, die auf den Tomcats läuft, kann ich schonmal ausschliessen, da der Tomcat ohne die eingebundenen Zusatz-Bibliotheken läuft. Das Start-Skript für den Tomcat sollte eigentlich so aussehen:
Funktionieren tut's aber nur, wenn das Setzen des LD_LIBRARY_PATH entfernt wird. in dem zusätzlich angegebenen Ordner befinden sich Dateien für tcnative. Verursacher ist vermutlich die libtcnative-1.so.
Die Systemdaten:
Das Problem scheint aber an der VM zu liegen, denn auf dem Host-System geht es ja. Ich denke daher, dass die libtcnative-1.so an irgendeiner Stelle nicht ausreichend Speicher o.ä. bekommt. Daher hier noch die OpenVZ-Einstellungen:
Vielleicht hat hier ja jemand eine Idee, wo genau das Problem liegt und ggf. auch gleich, wie ich es beheben kann.
Code:
#!/bin/sh
export CATALINA_OPTS=" -Xmx2000m -Xms2000m -XX:MaxPermSize=128m -Djvm.process.name=192.168.0.131-p0 -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.port=12090 "
export LC_ALL=C
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/data/meinefirma/app/p0/lib
export LD_LIBRARY_PATH
./startup.shFunktionieren tut's aber nur, wenn das Setzen des LD_LIBRARY_PATH entfernt wird. in dem zusätzlich angegebenen Ordner befinden sich Dateien für tcnative. Verursacher ist vermutlich die libtcnative-1.so.
Die Systemdaten:
Code:
rlimit: STACK 8192k, CORE 0k, NPROC infinity, NOFILE 8192, AS infinity
CPU:total 8 (4 cores per cpu, 1 threads per core) family 6 model 7 stepping 10, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3
Memory: 4k page, physical 7340032k(6082848k free), swap 9767512k(9767512k free)
vm_info: Java HotSpot(TM) 64-Bit Server VM (11.2-b01) for linux-amd64 JRE (1.6.0_12-b04)
uname:Linux 2.6.26-2-openvz-amd64
libc:glibc 2.7 NPTL 2.7
Tomcat: 6.0.26Das Problem scheint aber an der VM zu liegen, denn auf dem Host-System geht es ja. Ich denke daher, dass die libtcnative-1.so an irgendeiner Stelle nicht ausreichend Speicher o.ä. bekommt. Daher hier noch die OpenVZ-Einstellungen:
Code:
KMEMSIZE="16384000:18022400"
LOCKEDPAGES="1835008:1835008"
PRIVVMPAGES="1835008:1835008"
SHMPAGES="1835008:1835008"
NUMPROC="64000:64000"
PHYSPAGES="1835008:1835008"
VMGUARPAGES="1835008:1835008"
OOMGUARPAGES="1835008:1835008"
NUMTCPSOCK="9223372036854775807:9223372036854775807"
NUMFLOCK="8192:8192"
NUMPTY="1024:1024"
NUMSIGINFO="1024:1024"
TCPSNDBUF="402653184:402653184"
TCPRCVBUF="402653184:402653184"
OTHERSOCKBUF="9223372036854775807:9223372036854775807"
DGRAMRCVBUF="9223372036854775807:9223372036854775807"
NUMOTHERSOCK="9223372036854775807:9223372036854775807"
DCACHESIZE="9223372036854775807:9223372036854775807"
NUMFILE="9223372036854775807:9223372036854775807"
AVNUMPROC="2000:2000"
NUMIPTENT="128:128"
# Disk quota parameters (in form of softlimit:hardlimit)
DISKSPACE="31457280:31457280"
DISKINODES="3200000:3200000"
QUOTATIME="0"
# CPU fair sheduler parameter
CPUUNITS="1000"Vielleicht hat hier ja jemand eine Idee, wo genau das Problem liegt und ggf. auch gleich, wie ich es beheben kann.
