Grayback
I'm new here

Serverprobleme alle 4Tage

Hallo Leute,

Ich weiß nicht ob es genau hier hin gehört, aber man kann ja mal fragen.

Ich würde erstmal kurz unsere Komponenten und den Ablauf beschreiben und dann auf unser eigentliches Problem zu sprechen kommen.

Wir haben FirstSpirit 4.2.488 im Einsatz.

Unsere Webseiten hosten wir auf einem externen Server (Hoster: Host Europe).

Auf dem Server läuft ein Apache2, Tomcat6 und MySQL(in welcher Version weiß ich leider nicht).

Die Webseiten liegen auf einem anderen Server als unser FirstSpirit. Wenn ein Deployment gestartet wird, dann werden die Seiten

erst auf dem Server, wo auch FirstSpirit liegt generiert und dann mit der Hilfe eines RSyncs auf den Webseitenserver geschoben.

Von der Webseiten laufen täglich (nachts) Teildeployments, weil ein Volldeployment der Seite circa 16-18Stunden dauert. Deswegen wird jede Nacht ein Teildeployment gemacht, so das man am Ende der Woche ein Pseudo-Volldeployment gemacht hat.

Unser Hauptproblem ist, das der Webseitenserver circa alle 4Tage abschmiert. Somit die Webseiten auch nicht mehr erreichbar sind.

Um das Problem dann zu beheben muss der Tomcat und der Apache gestoppt werden, dann läuft jedoch immernoch ein Javaprozess, den ich dann killen muss. Danach starte ich Apache und Tomcat wieder und es läuft alles wieder.

Unsere Ideen dieses Problem zu beheben:

  • Flush-Hosts der MySQL Datenbank auf dem FirstSpirit Server -> ohne Erfolg
  • Manuelles Neustarten (später dann per Skript) des Servers aller 2Tage (somit eine kontrollierte Downtime zu haben) -> ohne Erfolg
  • Nagios (Monitoring) für den Server eingerichtet um zu erkennen ob es mit dem Deployments Nachts zusammenhängt -> tut es nicht, deshalb ohne Erfolg

Langsam gehen uns die Ideen aus. Deswegen frage ich mal hier. Vielleicht hat schon einmal jemand dasselbe oder ein ähnliches Problem gehabt.

Wenn ihr weitere Informationen braucht sagt Bescheid.

Ansonsten würde ich mich über jede Idee oder Lösungsvorschlag freuen.

Dankeschön

18 Replies

Hallo André,

wir haben die Situation nun mehrfach wieder gehabt und versucht, deinen Tipp anzuwenden.

Per jps haben wir die Prozess-ID recherchiert und dann jstack <Prozess-ID> > dump.txt den Dump gestartet.

Allerdings ist es im Moment des Tomcat-Aufhängens leider nicht mehr möglich, einen Dump zu ziehen.

jstack bricht mit einem Fehler ab, der ungefähr sagt: "Probably the HotSpot VM is not running."

(Den genauen Wortlaut habe ich leider nicht kopiert, da es dann mal wieder schnell gehen musste, den Server wenigstens wieder zum Laufen zu bewegen.)

Wir wären gern bereit, für das Problem externe Hilfe hinzuzuziehen, da wir nicht mehr weiter wissen.

Bitte kontaktiere uns doch mal, ob es seitens e-Spirit dazu Möglichkeiten gäbe.

Danke

Mathias

0 Kudos

Hallo Mathias und Kenny,

das Problem klingt nach einem Fehler, den ich bei einem früheren Arbeitgeber hatte. Das Setup klingt auch ähnlich (viele, viele JSPs und Tomcat). Die Fehlerlogs nicht unbedingt, aber die waren damals bei unserem Problem auch nicht immer gleich und eindeutig.

Bei uns lag es an einem Speicherproblem beim Tomcat; nach und nach lief der Heap voll, da der Tomcat in der Standardeinstellung jede jemals aufgerufene Seite im Speicher hält. Irgendwann ist der dann einfach voll - leider räumt er dann auch nichts ab meckert auch nicht immer sondern "freezed" teilweise soweit ein, dass nur noch ein kill hilft. Manchmal wurden die letzten freien Bytes sogar noch genutzt, um einen unvollständigen Stacktrace im Log zu hinterlassen.... Smiley Happy

Versucht mal in der web.xml die Einstellung "maxLoadedJsps" auf einen angemessenen Wert zu setzen - bei uns hat´s geholfen. Die Einstellung bewirkt ein "wegräumen" der ältesten Seiten im Speicher, wenn die Grenze erreicht wird. Je nach Seitenaufbau und Speichergröße kann dann hier begrenzt werden. Ich würde mit ein paar tausend Seiten anfangen und beobachten, wie voll der Speicher wird. Wenn da noch genügend Reserven sind, den Wert entsprechend erhöhen (damit man möglichst viele, schnelle Aufrufe hat). Geändert haben wir das damals unter $CATALINA_BASE/conf/web.xml, da wir auf der Instanz eh nur eine Web-App hatten. Vielleicht kann man es auch in der Web-App selbst einstellen.

Doku-Auszug:

maxLoadedJsps - The maximum number of JSPs that will be loaded for a web application. If more than this number of JSPs are loaded, the least recently used JSPs will be unloaded so that the number of JSPs loaded at any one time does not exceed this limit. A value of zero or less indicates no limit. [-1]

Gruß,

Sascha

0 Kudos

Hallo Sascha,

danke für deinen Tipp.

Für diese Ursache spricht die Tatsache, dass es periodisch alle x Tage passiert.

Funktioniert die Konfigurationsoption auch für JSF-Seiten?

Danke

Mathias

0 Kudos

Ich habe mich heute nochmal auf Ursachensuche begeben und bin in der catalina.properties auf den Wert

tomcat.util.buf.StringCache.byte.enabled = true

gestoßen.

Zumindest andere scheinen davor zu warnen:

https://jira.atlassian.com/browse/JRA-15394

Ich würde das mal deaktivieren, mal sehen was passiert. 🙂

Mathias

0 Kudos

Keine Ahnung, ob das für JSF auch wirkt.

Was den letzten Hinweis betrifft, dor steht in den Kommentaren ein Hinweis auf eine Begrenzung (ab v5.5.21 und 6.0.3) hin (200 x 128 Byte), welche sehr niedrig ist. Ich denke hieran liegt es nicht.

Gruß,

Sascha

0 Kudos

Hallo,

ich hätte da folgende Erfahrung:

bei jsf dürften die Seiten nicht mehr in Java übersetzt und compiliert werden. Wir hatten von einiger Zeit ein Projekt mit JSF und Facelets und da wurden die Seiten geparst (das mussten dann auch valide XHTML-Dateien sein). Problem bei dem damaligen Setup mit bis zu 100.000 Seiten war das Verhalten von Facelets, da wurde nach dem Parsen der Komponentenbaum in einem Cache im Applikationsserver gehalten und nie gelöscht. Wenn dann die Suchmaschine alles indizieren wollte, kam es zum Problem, Full GCs, nacher ein OOM. Lösung war damals aus dem Ewig Cache einen LRU-Cache zu machen.

Wie ist denn die Aktivität der Gargabe Kollektoren. Steigen da zu Zeiten an, gibt es öfter Full GCs?

0 Kudos

Hallo Sascha,

die Option maxLoadedJsps hat bei uns leider nicht geholfen.

Im Gegenteil, es gab einen Folgefehler, dass nicht mehr alle Seiten ausgeliefert wurden.

Wir probieren in Kürze einmal ein Update auf Tomcat 6.0.37 aus, da gab es einen Bugfix zu einem Memory-Leak im SecurityManager, vielleicht hilft das ja.

Viele Grüße

Mathias

0 Kudos

Hallo Mathias,

ich kenne mich zwar mit JSF nicht aus, aber du könntest dir noch mal die Dokumentation der verwendeten Implementierung anschauen, vielleicht gibt es da noch Optimierungspotential.

Auf jeden Fall scheinst du mit deinem Problem kein Einzelfall zu sein, eine Google-Suche gibt da etliche Treffer, z.B. https://community.jboss.org/thread/11084?start=0&tstart=0&_sscc=t

Viele Grüße

Thorsten

0 Kudos

Hallo,

wir haben so ein ähnliches Szenario (FS generiert im Wesentlichen JSPs, die per rsync auf Frontendserver gepusht werden) bei der Bauer Digital und nach meiner Erfahrung, wäre es hier sinnvoll zunächst auf den neuesten Tomcat 7 zu updaten - das hatte bei uns seinerzeit schonmal einen signikanten Boost gebracht.

Der Clou einen Application-Server mit dem Überladen von potentiell tausenden immer wieder zu ladenden JSPs nicht unnötig in die Knie zu zwingen, besteht aus einem Zusammenspiel zwischen:

* Jasper-Einstellungen, siehe: http://tomcat.apache.org/tomcat-7.0-doc/jasper-howto.html#Configuration

* insbesondere unter Berücksichtigung der Parameter für den Produktivbetrieb: http://tomcat.apache.org/tomcat-7.0-doc/jasper-howto.html#Production_Configuration

* VM- bzw. GC-Einstellungen: -server -d64 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC  (um nur einige basics zu nennen)

* der richtigen Konfiguration des HTTP-Connectors (in der server.xml) - hier wird aus development-Umgebungen gerne vergessen realistische Zahlen (~1000 Prozessoren) für den Livebetrieb einzutragen

* Caching (entweder durch einfaches Anpassen der Header, z.B. mit https://github.com/samaxes/javaee-cache-filter oder etwas eleganter (wenn auch nicht so straight-forward und eher durch Dev-Ops zu erledigen, mittels Varnish)

* regelmäßigem Monitoring und Profiling von Heap und Perm-Speicher der VM - wenn man hier frühzeitig in der Entwicklungsphase bzw. in der ersten Zeit nach Go-Live von Projekten Aufwand reinsteckt, wird man später belohnt - klingt abgedroschen, ist aber leider so.

beste Grüße aus Hamburg,

Nils Weber

Bauer Digital KG