Tomcat Speicherverwaltung

[gnoovy]

Hi Zusammen,

ich habe mir von Apache die Tomcat binaries geladen und mittels selbergebautem StartScript laufen lassen. Ansich funktioniert alles, allerdings möchte ich die Speicherverwaltung von Tomcat noch anpassen. Unter Windows gibt es ja im Tomcat-GUI das Initial und Max Memory Pool. Unter Linux habe ich über Google in Erfahrung gebracht, dass es hierfür in der catalina.sh die Zeile:

CATALINA_OPTS="$CATALINA_OPTS -server -Xms256m -Xmx2048m -XXermSize=512m -XX:MaxPermSize=512m $JPDA_OPTS"

anpassen soll. Weiter hab ich noch gelesen, dass man aber auch eine setenv.sh mit:

export JAVA_OPTS="-Xms256m -Xmx2048m -XX:MaxPermSize=512m"

erstellen soll. Aber was stimmt denn nun? Ich möchte den Speicher analog wie unter Windows konfigurieren. Also den Xms, Xmx und MaxPermSize.

 

[bitmuncher]

Beide Möglichkeiten funktionieren. Allerdings ist es unüblich die catalina.sh zu bearbeiten, wenn man die Umgebung definieren will, denn genau dafür ist die setenv.sh gedacht. Wenn du mal einen Blick in die catalina.sh wirfst, findest du darin Abschnitte wie den folgenden:

if [ -r "$CATALINA_BASE/bin/setenv.sh" ]; then
  . "$CATALINA_BASE/bin/setenv.sh"

D.h. also, dass die setenv.sh "ausgeführt"/geladen wird, wenn sie für den User, der Tomcat startet, ausführbar ist.

Fazit: Der saubere Weg führt über die setenv.sh. Es sind aber beide Wege möglich. Auf jeden Fall musst du es nicht doppelt machen indem du es in beide Dateien einträgst, da ja die setenv.sh sowieso beim Ausführen der catalina.sh ausgeführt wird.

 

[marce]

beides geht - TomCat läuft ja mit Java und Java startet normalerweise mit den entsprechenden Umgebungsvariablen.

Sinnvoller ist es allerdings, daß im ded. Start-Script vom Tomcat zu setzen und dort die Umgebungsvariablen von Java zu ignorieren, da man so eine ded. Kontroller bekommt, vor allem, wenn man mal mehr als einen TomCat auf dem System laufen hat...

 

[bitmuncher]

Sinnvoller ist es allerdings, daß im ded. Start-Script vom Tomcat zu setzen und dort die Umgebungsvariablen von Java zu ignorieren, da man so eine ded. Kontroller bekommt, vor allem, wenn man mal mehr als einen TomCat auf dem System laufen hat...

Das würde aber den Sinn der setenv.sh ad absurdum führen. Diese Datei soll schliesslich die Laufzeit-Umgebung des Tomcat definieren. Dort kann man z.B. auch seinen $PATH einschränken usw.. Und es hat auch seine Gründe warum diverse Parameter von der catalina.sh aus Umgebungsvariablen geladen werden und nicht fest im Skript verankert sind. Wäre ein Bearbeiten des Startskripts vorgesehen, wäre das nicht notwendig.

Tatsache ist auch, dass es bei einem professionellen Deployment (mit Tools wie Chef, Puppet, cfengine, Rex o.ä.) wesentlich einfacher ist eine Datei (die setenv.sh) auszulassen als zu prüfen ob sich die neue catalina.sh geändert hat und diese dann mit einer bestehenden Version zu mergen.

 

[marce]

ich meinte auch nicht die catalina.sh sondern würde dafür eher entweder ein init-Script erstellen oder ein ded. Script, welches den TomCat startet / stopt.

So machen wir das seit Jahren und mit eigentlich nur guten Erfahrungen - man muss sich keine Gedanken bei Updates machen, da die Original-Dateien vom TomCat nicht verändert werden, kann problemlos mehrere Nutzerkonten verwenden, jeder Java-App ihre eigene Konfiguration für Java (und ggf. sogar ded. Java-Versionen) zuweisen und hat parallel auch keine Problem mit den allg. envs auf dem System.

So liefen bei uns mit 15 unterschiedlichen Nutzern 3 verschiedene TomCat-Versionen (mit jeweils zugeordneter Java-Version) in bis zu 10 Instanzen mit jeweils eigener Speicher-Konfiguration, je nach dem wie die jeweilige Applikation das brauchte.

 

[bitmuncher]

Wenn ihr ernsthaft mit so vielen verschiedenen Envs innerhalb eines Systems rumhantieren müsst, solltet ihr euch ggf. mal Container-Virtualisierung wie Docker oder OpenVZ anschauen. Da bekommt man solche Konflikte gar nicht erst und kann auf zig Init-Skripte für quasi den gleichen Service problemlos verzichten.

 

[marce]

Docker gab's damals noch nicht und Virtualisierung für ded. Anwendungen war / ist der Overhead (im weitesten Sinne) zu groß.

Konflikte haben auch keine - bzw. wir umgehen sie eben. Die TomCats laufen jeweils unter einem eigenen User, der hat sein env und das entsprechende Start-Script. Deploy ist im schlimmsten Fall (selbst wenn mal ein kompletter TomCat mit erstellt werden muss) nicht viel mehr als ein tar.gz entpacken :-)

Ist zugegeben in dem Konstrukt auch ein wenig historisch gewachsen, heute könnte man da vieles anders machen, nachteilig oder schlecht empfinde ich den Weg aber immer noch nicht... Vor allem, wenn man mal mehrere Instanzen der gleichen Anwendung braucht, aber deswegen nicht gleich eine neue VM, Server oder sonst was aufbauen will...

 

[gnoovy]

Hi Zuammen,

vielen Dank für eure Hilfe. Mich verwundert es nur, dass in den tomcat binaries download der 7er Version in der catalina.sh die catalina_opts bereits mit der Konfiguration meines Eingangsposts bereits befüllt ist. Werden die Werte somit überhaupt verwendet?

Ausschnitt catalina.sh

# Bugzilla 37848: only output this if we have a TTY
if [ $have_tty -eq 1 ]; then
echo "Using CATALINA_BASE: $CATALINA_BASE"
echo "Using CATALINA_HOME: $CATALINA_HOME"
echo "Using CATALINA_TMPDIR: $CATALINA_TMPDIR"
if [ "$1" = "debug" ] ; then
echo "Using JAVA_HOME: $JAVA_HOME"
else
echo "Using JRE_HOME: $JRE_HOME"
fi
echo "Using CLASSPATH: $CLASSPATH"
if [ ! -z "$CATALINA_PID" ]; then
echo "Using CATALINA_PID: $CATALINA_PID"
fi
fi

if [ "$1" = "jpda" ] ; then
if [ -z "$JPDA_TRANSPORT" ]; then
JPDA_TRANSPORT="dt_socket"
fi
if [ -z "$JPDA_ADDRESS" ]; then
JPDA_ADDRESS="8000"
fi
if [ -z "$JPDA_SUSPEND" ]; then
JPDA_SUSPEND="n"
fi
if [ -z "$JPDA_OPTS" ]; then
JPDA_OPTS="-agentlib:jdwp=transport=$JPDA_TRANSPORT,address=$JPDA_ADDRESS,server=y,suspend=$JPDA_SUSPEND"
fi
CATALINA_OPTS="$CATALINA_OPTS -server -Xms256m -Xmx2048m -XXermSize=512m -XX:MaxPermSize=512m $JPDA_OPTS"
shift
fi

 

[bitmuncher]

Wie du ja sehen kannst, werden die Parameter lediglich als zusätzlicher Wert an CATALINA_OPTS angehängt.

CATALINA_OPTS="$CATALINA_OPTS -server -Xms256m -Xmx2048m -XXermSize=512m -XX:MaxPermSize=512m $JPDA_OPTS"

D.h. also wenn die CATALINA_OPTS irgendwo anders schon gesetzt wird, werden die Werte, die in der catalina.sh eingetragen sind, an diese angefügt.

 

[gnoovy]

Hi bitmuncher,

hmm... ok aber ich habe so im Grundsatz nichts definiert. Wird denn im Standard von Tomcat die CATALINA_OPTS bereits irgendwo gesetzt? Oder sind dann diese Speicherangaben somit noch inaktiv?

 

[marce]

wenn Du nichts gesetzt hast bleiben die Default-Einstellungen von der catalina.sh aktiv.

Sollte sich aber auch im Logfile ablesen lassen - da wird AFAIK das ganze Gedöhns beim Start geloggt.