Springe zum Inhalt

Java in Serveranwendungen: Enttäuschung ohne Ende

Hat schon mal jemand eine Java-Serveranwendung betrieben? Tomcat oder dergleichen? Wenn ja, wird derjenige mir hier bestimmt zustimmen: Java ist meiner Meinung nach kein geeignetes Paket für eine Serveranwendung. Sich allein mit der Sprache zu befassen reicht nicht aus, man muss tief in die verwinkeltsten Züge der VM absteigen, um zu begreifen, wie dieses Biest arbeitet (oder auch nicht). Und erst wenn der Anwender das verstanden hat, kann er eine Java-Serveranwendung (wahrscheinlich) einigermaßen stabil laufen lassen. Alles andere funktioniert nicht.

SnipSnap

Über die Jahre hinweg habe ich mehrere Java-Serveranwendungen eingesetzt. Angefangen mit der uralten und wirklich positiv in Erinnerung gebliebenen Wiki-Software SnipSnap. Offensichtlich wussten die Entwickler hier, was sie taten. Die Software war mehrere Jahre firmenintern im Einsatz. Aber auch deren Start war holprig. Das Speichermanagement musste genau angepasst werden.

Vielleicht mag es Anwender geben, die mit folgenden Optionen umgehen können:

  1.     -Xms<size>        Legt anfängliche Java Heap-Größe fest
  2.     -Xmx<size>        Legt maximale Java Heap-Größe fest
  3.     -Xss<size>        Legt Java-Threadstackgröße fest

Ich kann es ohne genaue Kenntnis der Anwendungsinternas nicht. Ich muss mich auf die Angaben des Herstellers zu den Systemanforderungen verlassen und stelle das dann entsprechend ein.

Freenet

Abgesehen vom wirklich positiven Eindruck von SnipSnap (Ausnahmen bestätigen die Regel), war meine nächste Java-Serveranwendung Freenet. Ein freies, unreguliertes und unzensiertes Netzwerk. Die Referenzimplementation für dieses Netzwerk ist in Java geschrieben. Ob man nun Oracles Java oder die freie Implementierung OpenJRE/JDK verwendet: es ist nicht stabil zum Laufen zu bekommen, egal, wie groß die Kiste ist.

Unter dem Motto der Portabilität waren auch noch viele Desktop-Anwendungen für dieses Netzwerk in Java geschrieben, die eher schlecht als recht funktioniert haben.

Höhepunkt war dann eine Watchdog, die aufpasste, wann Freenet wieder einmal abgestürzt war und es in diesem Falle neu startete.

JaCy

Vor Kurzem habe ich es dann wieder einmal versucht: JaCy, eine nicht zensierbare per P2P verteilte Suchmaschine, die ebenfalls in Java entwickelt wurde. Anfänglich war ich überrascht über die wenigen Abhängigkeiten (eigentlich nur Java) und der einfachen Installation mit vielleicht drei oder vier Optionen, aberundet mit einer wirklich ansprechenden Weboberfläche. Aber auch hier zeigte sich, dass Java nicht so einfach in den Griff zu bekommen ist, besser gesagt: das Speichermanagement von Java. JaCy wird mit einer Defaulteinstellung von max. 600 MB für die Java-VM ausgeliefert. Das sollte eigentlich für jeden durchschnittlichen Server mehr als ausreichend sein. Wie man aber dann nach kurzer Zeit Laufzeit sieht, pumpt sich der virtuelle Speicher des Prozesses schon mal auf gute 1,6 GB auf... Warum?

Testweise habe ich JaCy in eine VM mit 2 GB RAM eingesperrt. Sobald man die Anwendung jedoch ein paar Sachen tun lässt, sprengt nach kurzer Zeit der Speicherhunger von Java jeden Rahmen und hält sich keinesfalls an die vorkonfigurierten Maximalwerte. Zumal das Java-interne Speichermanagement diesen Schwellzustand offensichtlich mitbekommt, anschließend aber nur noch damit beschäftigt ist, Garbage Collections durchzuführen, welche anscheinend nichts bringen, und so den Prozess dauerhaft auf Maximal-CPU-Last fahren. Quasi ein Deadlock zwischen Anforderung und GC.

Desktopanwendungen

Ganz ehrlich: man kann in Java wirklich tolle Sachen programmieren. So z.B. Eclipse. Eine Anwendung, die ich wirklich sehr oft nutze und von deren Funktionsumfang ich immer wieder überwältigt bin. Daneben gibt es noch eine ganze Menge kleinerer Java-Desktopanwendungen, welche klaglos funktionieren.

Und last but not least sind ja ein Großteil der auf Smartphones eingesetzten Apps in Java geschrieben. So schlecht kann die Sprache also nicht sein.

Allein als Serveranwendung finde ich sie bisher ungeeignet.

5 Gedanken zu „Java in Serveranwendungen: Enttäuschung ohne Ende

  1. Schroeffu

    :-D Das bringt mich zum Schmunzeln, Java ist vermutlich die nerventötenste Sprache wenn es ums Speichermanagement geht.

    Middleware Server (Tomcat/Weblogic) verwalten sind mein Täglich Brot. Und ja es stimmt, es geht bei den Abstürzen zu 40% um zu wenig Memory oder Leaks die den Fehler provozieren.

    Wenns soweit ist hilft nur erhöhen, wenns wieder klemmt Threaddumps und wenns ein Leak ist einen Heapdump analysieren.

    Kleiner Tipp: Xmx und Xms einfach immer denselben Wert benutzen, so schnappt sich Java schonmal den Maximalwert und muss nicht dynamisch hochrechnen im Verlauf der Zeit. Ungleiche Werte sind unnütz so meine Erfahrung.

  2. Schroeffu

    Ps: Yacy pumpt sich die indexierten Dokumente in die Memory, denn nur wenn sie in den RAM sind funktioniert die blitzschnelle Suche auch wirklich blitzschnell.

    Yacy setzt auf Solr, ein Konkurrenzprodukt zu ElasticSearch. Diese Echtzeit Suchmechanismen (Autovervollständigung wie Google, Millisekunden Reaktionen bei Abfragen ohne Datenbankrequest) bedingen immer, dass die Indexe im Memory stehen als Kopie dessen was auf der Festplatte ist.

    Je grösser ein Index, je höher der RAM Verbrauch. Wenn Xmx zu klein ist, holt Yacy die Indexe zuerst von der Festplatte in die RAM um dann diese zu durchsuchen, ähnlich negativ wie Swapping, dann ist die schnelle Suche nämlich beinahr "tot" und hat gerne 1-20 Sekunden Antwortzeiten.

    Bei ElasticSearch baut man sich deswegen gerne Cluster mit jeweils Xmx mindestens so hoch, wie der (gesplittete) Index auf der HDD dick ist.

    :-)

  3. marius

    Schlecht geschriebene Software gibts zuhauf. Memoryleaks sind kein Java- oder Webserverproblem, sondern Folge von schlechten/(für Entwickler)zu komplexem Code.

    Ich betreibe seit Jahren fette Javaserveranwendungen und habe solche Probleme nicht.

  4. Tux.

    Ich bezweifle allerdings, dass YaCy in einer anderen Sprache merklich sparsamer mit dem Speicher umgehen würde. Es macht eben eine Menge Dinge mit sehr vielen Daten.

  5. Blubberbart

    Mit der Default-Konfiguration ist das auch so eine Sache. Je nach Einsatzgebiet muss man eben doch wieder Hand anlegen. Als Entwickler kann man schlecht vorhersehen, wie die genau richtige Default-Konfiguration auf dem jeweiligen Server mit entsprechendem Einsatzgebiet aussieht. Im zweifel liegt man immer daneben. Dabei finde ich so etwas, wie Speicher zuweisen, noch vergleichsweise simpel.

Kommentare sind geschlossen.