Java Performance- und Speicherprobleme bei Webanwendung auf Basis Java/Tomcat

Guten Morgen zusammen,

ich habe hier eine Java-/Tomcat-basierende Webanwendung.

Immer wieder haben wir Performanceprobleme am Frontend, sprich an der User-Sicht im Internet Explorer kommt es zu ewig langen Wartezeiten. In den Tomcat-Logs sind einige memory/performance Einträge zu finden.

Kennt sich jemand damit aus - finden leider keinen Stellhebel, um das Problem zu fixen.

Vielen Dank vorab!

VG Toni

Dez 02, 2016 1:31:38 PM org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks
SEVERE: The web application [/SNPortal] created a ThreadLocal with key of type [net.sourceforge.jtds.jdbc.DateTime$1] (value [net.sourceforge.jtds.jdbc.DateTime$1@6da605a3]) and a value of type [java.util.GregorianCalendar] (value [java.util.GregorianCalendar[time=1454489381000,areFieldsSet=true,areAllFieldsSet=false,lenient=true,zone=sun.util.calendar.ZoneInfo[id="Europe/Berlin",offset=3600000,dstSavings=3600000,useDaylight=true,transitions=143,lastRule=java.util.SimpleTimeZone[id=Europe/Berlin,offset=3600000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=1,startTime=3600000,startTimeMode=2,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=1,endTime=3600000,endTimeMode=2]],firstDayOfWeek=2,minimalDaysInFirstWeek=4,ERA=1,YEAR=2016,MONTH=1,WEEK_OF_YEAR=5,WEEK_OF_MONTH=1,DAY_OF_MONTH=3,DAY_OF_YEAR=34,DAY_OF_WEEK=4,DAY_OF_WEEK_IN_MONTH=1,AM_PM=0,HOUR=9,HOUR_OF_DAY=9,MINUTE=49,SECOND=41,MILLISECOND=0,ZONE_OFFSET=3600000,DST_OFFSET=0]]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak.

Zum Vergrößern anklicken....

Dez 02, 2016 1:37:15 PM org.apache.catalina.core.AprLifecycleListener init
INFO: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: D:\SNWeb\apache-tomcat-6.0.36\bin;C:\Windows\Sun\Java\bin;C:\Windows\system32;C:\Windows;C:\win64app\nsr\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\SPBinstaller;C:\Program Files (x86)\hotfixinstaller;C:\Program Files\System Center Operations Manager 2007\;C:\Perl64\site\bin;C:\Perl64\bin;L:\MSSQL(x86)\100\Tools\Binn\;L:\MSSQL\100\Tools\Binn\;L:\MSSQL\100\DTS\Binn\;L:\MSSQL(x86)\100\Tools\Binn\VSShell\Common7\IDE\;C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\;L:\MSSQL(x86)\100\DTS\Binn\;D:\Java\bin;C:\Program Files (x86)\ManageSoft\Common;C:\Program Files\NetApp\Windows Host Utilities\;;.
Dez 02, 2016 1:37:15 PM org.apache.tomcat.util.digester.SetPropertiesRule begin
WARNING: [SetPropertiesRule]{Server/Service/Engine/Realm} Setting property 'debug' to '99' did not find a matching property.

Zum Vergrößern anklicken....

Dez 02, 2016 2:02:53 PM org.apache.coyote.http11.Http11Processor process
SEVERE: Error processing request
java.lang.OutOfMemoryError: GC overhead limit exceeded

Zum Vergrößern anklicken....

Welche Startparamter hat der Tomcat?
Mir geht es vorallem um -Xmx und ähnliches.

Was verstehst du unter "ewigen Wartezeiten"?

Deine Applikation rennt ins Speicherlimit, da ist es klar, dass es schlagartig langsam wird oder die Anwendung komplett crashed.

Du solltest mal den Speicher, den du Tomcat zur Verfügung stellst erhöhen.
Hier eine Anleitung dazu: http://crunchify.com/how-to-change-jvm-heap-setting-xms-xmx-of-tomcat/

Im ersten Block meckert der Tomcat, dass Deine Application Objekte ThreadLocal-Objekte generiert, die beim Shutdown nicht sauber abgeräumt werden.
Arbeitest Du aktiv (bewußt) mit ThreadLocal? Falls ja, baue eine Implementierung in Deine Applikation, die die Objekte beim Runterfahren abräumt. Falls nein, macht das wohl eine der libs, die Du mit verwendest. Da kannst Du nur mal kucken, ob es vielleicht aktuellere Versionen der libs gibt, die Du verwendest.

Mit dem zweiten Block kann ich nix anfangen. Ich kenne die lib nicht, die da vorgeschlagen wird. Ob das wirklich wichtig ist, kann ich nicht beurteilen.

Der dritte Block sagt, DASS Du ein Speicherproblem hast. Aber nicht, warum.
Ich würde versuchen, Dich mit VisualVM ([Java-Speicherort]/bin/jvisualvm.exe) auf den Tomcat draufzuschalten und mindestens mal zu beobachten, ab wann Deine Speicherlast ansteigt.

Abgesehen davon: Speicherprobleme mit einer Applikation kriegst Du wegen der Art und Weise, wie Deine Applikation aufgezogen ist und wie sie funktioniert.
Dazu steht hier überhaupt nichts. Daher wird Dir auch keiner sagen können, warum Du Speicherprobleme hast oder wie sie zu lösen wären.

Nachtrag zu Block 1: Die genannten Memory-Leak Probleme wirken sich aus, wenn die Applikation im Tomcat gestoppt wird. Anders gesagt: Solange der Tomcat läuft, in dem Deine Applikation mitläuft, ist es möglich, dass Deine Applikation bei jedem Stop (Undeployment, manueller Stop) ein bischen Speicher nicht mehr freigibt. Lässt man den Tomcat immer laufen und deployt "nur" die Anwendung immer wieder oder startet sie durch, summiert sich das immer mehr.

Für dieses Problem gibt es einen einfachen Ansatz, mit dem sich zumindest die Symptome bekämpfen lassen: Wird der ganze Tomcat durchgestartet, ist erstmal alles wieder sauber. Man könnte also über einen automatisch geplanten Neustart nachdenken, einmal pro Woche Sonntag Abend oder so ähnlich.

Unser Projektpartner hat nur empfohlen, den Speicher über die Tomcat-Optionen zu erhöhen - scheint aber nicht der Bringer zu sein


Darüber hinaus wurde vorgeschlagen eine setenv.bat zu erstellen - siehe Screenshot.
Aber die Einstellung hatte auch keinen Effekt.

Ich denke, du wirst um VisualVM schlecht drumrum kommen, wenn die Erhöhung des verfügbaren Speichers nichts bringt.

Es gibt einfach nicht >die Eine< Lösung bei Speicherproblemen. Es ist ein Zusammenspiel aus OS, VM, JVM, Tomcat und der eigentlichen Anwendung ...
Und es wurde ja noch nichtmal gesagt, was für eine Art von Anwendung es ist, wie viele Nutzer drauf sind, welche Technologien eingesetzt werden oder wann der Fehler auftritt.

Bisher ist das hier reines Ratespiel und macht keinerlei Sinn.

Welche Hardware/OS läuft da überhaupt?
Wenn die z. B. nur 8GB RAM hat, dann wird es mit 16GB eng

Eine wichtige Fehlermeldung ist sicher diese hier "java.lang.OutOfMemoryError: GC overhead limit exceeded" und durch googlen habe ich das hier gefunden:
http://stackoverflow.com/questions/5839359/java-lang-outofmemoryerror-gc-overhead-limit-exceeded
Da sind jede menge Tipps.. helfen die?
Oder diese? http://codekicker.de/fragen/Was-bedeutet-GC-overhead-limit-exceeded-bei-Java/203

Statt einfach mehr Ram auf das Problem zu werfen, sollte man vielleicht eher schauen, wo das Problem in der Anwendung ist. Auch wenn der Speicher von Java Anwendungen von der VM/Garbage Collector gemanaged wird, kann es zu Memory Leaks kommen.

Ein Hinweis gibt es dazu in der Meldung:

The web application [/SNPortal] created a ThreadLocal with key of type [net.sourceforge.jtds.jdbc.DateTime$1] (value [net.sourceforge.jtds.jdbc.DateTime$1@6da605a3]) and a value of type [java.util.GregorianCalendar] [..]

but failed to remove it when the web application was stopped. This is very likely to create a memory leak.

folgender SO Post erklärt es schön:

http://stackoverflow.com/questions/6470651/creating-a-memory-leak-with-java

Wenn du also mehr RAM auf das Problem wirfst, kommt der Fehler auch, nur halt später.

Memoryleaks sind ein schwieriges Thema. Weil es sie gibt, rebooten wir unsere Tomcats jeden Tag um 5 Uhr.
Wir sind natürlich ständig dran, diese zu reduzieren. Wir spüren sie auf, indem wir Memorydumps ziehen (lokal geht natürlich auch VisualVM) und dann diese analysieren. Hier sieht man schnell, in welchen Bereichen der Speicher verbraucht wird. Manches ist Ok, manches eben nicht. Z. B. war in meinem Großprojekt ein Webservice-Client an einem Leak die Ursache. Der wurde vom GC einfach nicht mehr frei gegeben. Abhilfe war hier der Austausch des WS-Frameworks (das war eh ein ziemlicher Wildwuchs mit unterschiedlichen Frameworks), aber das war ein Aufwand von mehreren 100 Stunden. Außerdem mussten abhängige Frameworks erst mal hochgezogen werden. Sowas wird nicht einfach mal nebenbei gemacht und die Kosten sind ein weiteres Thema, was solche Umbauten verzögert.

PS: wenn es mehrere Tomcats mit Loadbalancer gibt, dann kann man die auch zeitlich versetzt rebooten und hat dann keinen Ausfall.