Serverprobleme alle 4Tage
Author: Grayback
Publication Date: 8/14/2013 14:55
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
Tags: fs4.2, mysql, serverproblem
-
Author: andre - 8/14/2013 15:08
> Webseitenserver circa alle 4Tage abschmiert.
also der Apache2 antwortet nicht mehr oder beim Tomcat liegt das Problem? ist der tomcat-manager erreichbar? also diese manager html console des tomcats?
> dann läuft jedoch immernoch ein Javaprozess, den ich dann killen muss.
man koennte schauen, ob mal mittels "jps" mehr infos ueber den java-prozess bekommt und/oder jstack [pid des java-prozesses]
ausserdem kann man probieren sich mittels jconsole auf den java-prozess zu verbinden um rauszubekommen welche java-vm das ist.
gibt es exceptions im log (firstspirit und tomcat) out of memory o.ä.?
> circa 16-18Stunden
und kein optimierungspotential?
0 -
Author: Grayback - 8/14/2013 15:15
Hallo André,
Aus dem Stehgreif kann ich dir nichtmal sagen welcher das Problem verursacht. Ich müsste es Probieren wenn das nächste mal das Serverproblem eintritt.
Auf den Java-Prozess verbinden? Geht das? Ok ich hätte dazu sagen sollen das ich was Konsolenbefehle angeht Neuling bin. :smileyhappy:
Aber ich werde es mal probieren.
Im Firstspirit-Log gibt es keine Exceptions und im Tomcat auch nicht (wobei ich mir beim Tomcat grad nicht 100%ig sicher bin).
Und zu der langen Deploymentzeit, ja klar hätte das Optimierungspotenzial. Aber ist leider derzeit nicht geplant. :smileysad:
0 -
Author: andre - 8/14/2013 15:50
Auf den Java-Prozess verbinden? Geht das? Ok ich hätte dazu sagen sollen das ich was Konsolenbefehle angeht Neuling bin. :smileyhappy:
Aber ich werde es mal probieren.
jconsole heisst das tool. sollte bereits installiert sein, sowohl unter linux als auch windows.
http://docs.oracle.com/javase/6/docs/technotes/guides/management/jconsole.html
0 -
Author: Grayback - 8/15/2013 8:19
Heute früh war es wieder soweit. Die Webseiten waren weg.
Leider mussten die Seiten schnell wieder da sein, so dass ich mich nicht auf den Javaprozess verbinden konnte.
Jedoch habe ich mir mal den Status vom Apache und Tomcat angeschaut und so wie es aussieht verursacht der Tomcat das Problem. Weil der Apache unter einer ganz anderen PID läuft als der Javaprozess, welcher sich immer aufhängt.
Dazu wäre noch anzumerken, der Javaprozess hat dann immer eine CPU-Auslastung von 150% (oder mehr).
Das letzte Mal war es Sonntagabend. Also wieder 4Tage zwischen den ausfällen. Ich werde Samstag den Server noch einmal kontrolliert neustarten in der Hoffnung das die Webseiten dann Montag nicht wieder weg sind.
0 -
Author: feddersen - 8/15/2013 8:26
Nur zum Verständnis: Geht es um den Tomcat, der die Webseiten ausliefert oder geht es um einen Tomcat der die FirstSpirit Vorschau/Webedit etc. bereitstellt? Hört sich eher nach ersterem an.
Liefert der Tomcat vielleicht viele JSP-Seiten aus? Sind noch irgendwelche anderen Webanwendungen auf dem Tomcat aktiv? Die Logfiles des Tomcats sollten Hinweise liefern, was passiert.
0 -
Author: Grayback - 8/15/2013 8:31
Ja es handelt sich um einen Tomcat, welcher die Webseiten ausliefert.
Naja das Projekt hat sehr viele Seiten, deswegen auch die Volldeploymentzeit von 16-18 Stunden.
Und es sind keine JSP-Seiten sondern wir haben Anfang des Jahres unsere kompletten Seiten auf JSF umgestellt.
Aus den Logs werde ich nicht schlau.
Der Ausfall fand 04:19Uhr statt.
Die einzigen Einträge im Log in dem Zeitraum sind einmal 03:25 und dann erst wieder 04:30.
Kein Eintrag zu der Zeit als die Webseiten ausfielen.
0 -
Author: andre - 8/15/2013 9:54
> Dazu wäre noch anzumerken, der Javaprozess hat dann immer eine CPU-Auslastung von 150% (oder
mehr).
wenn das problem des tomcats auftritt, mal einen dump machen.
mittels jstack [java-process-pid]
statt der jconsole mal jvisualvm nutzen (wird auch mit dem jdk installiert) und unter threads schauen welcher die cpu-zeit verbraucht. auf dem threads-tab kann man auch einen threaddump machen.
0 -
Author: mlieber - 8/28/2013 15:40
Hallo André, Christoph, Kenny,
heute war es bei uns wieder so weit.
Ich konnte dabei ein paar Logs mitschneiden und dazu habe ich auch noch einige Softwareversionen aufgeschrieben, in der Hoffnung, das hilft etwas weiter. Jeder Tipp wäre sehr hilfreich.
- Tomcat 6.0.36
- Oracle Java JDK 1.6.0.41_b02
- libapache2-mod-jk 1.2.28-2
- mysql-connector-java-5.1.23-bin.jar
Verwendete Klassen im Web-Projekt:
<firstspirit.version>4.2.488</firstspirit.version>
<firstspirit.version.prod>4.2.488</firstspirit.version.prod>
<guava.version>12.0</guava.version>
<jsf.version>1.2_15-B02</jsf.version>
<richfaces.version>3.3.3.Final</richfaces.version>
<seam.version>2.2.2.Final</seam.version>
<seam.servlet.path>/*</seam.servlet.path>
<myfaces.tomahawk.version>1.1.14</myfaces.tomahawk.version>
<mysql.version>5.1.21</mysql.version>
<junit.version>4.10</junit.version>
<testng.version>5.8</testng.version>
<jboss.embedded.version>beta3.SP10</jboss.embedded.version>
<javax.activation.version>1.1</javax.activation.version>
<slf4j.version>1.6.1</slf4j.version>
<javax.el.version>1.0</javax.el.version>Folgendes erstes Log entstand einige Stunden vor dem Absturz. Könnte sein, dass sich Meldungen wie diese "aufstauen" und dann den Folge-Fehler verursachen:
Aug 23, 2013 6:03:54 AM org.apache.catalina.session.StandardSession expire
SEVERE: Session event listener threw exception
java.lang.IllegalStateException: Please end the HttpSession via org.jboss.seam.web.Session.instance().invalidate()
at org.jboss.seam.contexts.Lifecycle.endSession(Lifecycle.java:267)
at org.jboss.seam.contexts.ServletLifecycle.endSession(ServletLifecycle.java:187)
at org.jboss.seam.servlet.SeamListener.sessionDestroyed(SeamListener.java:59)
at org.apache.catalina.session.StandardSession.expire(StandardSession.java:720)
at org.apache.catalina.session.StandardSession.isValid(StandardSession.java:587)
at org.apache.catalina.connector.Request.doGetSession(Request.java:2406)
at org.apache.catalina.connector.Request.getSession(Request.java:2157)
at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:833)
at javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216)
at com.sun.faces.context.SessionMap.getSession(ExternalContextImpl.java:1006)
at com.sun.faces.context.SessionMap.get(ExternalContextImpl.java:961)
at org.jboss.seam.contexts.ServerConversationContext.get(ServerConversationContext.java:110)
at org.jboss.seam.Component.getInstance(Component.java:2002)
at org.jboss.seam.Component.getInstance(Component.java:1997)
at org.jboss.seam.Component.getInstance(Component.java:1970)
at org.jboss.seam.Component.getInstance(Component.java:1965)
at org.jboss.seam.core.Conversation.instance(Conversation.java:124)
at org.jboss.seam.faces.FacesManager.prepareBackswitch(FacesManager.java:260)
at org.jboss.seam.jsf.SeamPhaseListener.beforeRenderResponse(SeamPhaseListener.java:486)
at org.jboss.seam.jsf.SeamPhaseListener.beforeServletPhase(SeamPhaseListener.java:147)
at org.jboss.seam.jsf.SeamPhaseListener.beforePhase(SeamPhaseListener.java:117)
at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:214)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:96)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:374)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:40)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:206)
at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:388)
at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:515)
at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:60)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:615)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:311)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:776)
at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:705)
at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:898)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)
at java.lang.Thread.run(Thread.java:662)
Und dann habe ich diese Fehler zur Zeit des Absturzes aus dem catalina-Log extrahieren können:
Aug 28, 2013 3:29:25 PM org.apache.catalina.core.ApplicationDispatcher invoke
SEVERE: Servlet.service() for servlet Faces Servlet threw exception
org.jboss.seam.core.LockTimeoutException: could not acquire lock on @Synchronized component: profilViewHelper
at org.jboss.seam.core.SynchronizationInterceptor.aroundInvoke(SynchronizationInterceptor.java:41)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107)
at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:185)
at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:103)
at de.softwareforen.fs.portal.viewhelper.ProfilViewHelper_$$_javassist_seam_8.setLastLoginDate(ProfilViewHelper_$$_javassist_seam_8.java)
at sun.reflect.GeneratedMethodAccessor610.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:335)
at org.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:280)
at org.jboss.el.parser.AstMethodSuffix.getValue(AstMethodSuffix.java:59)
at org.jboss.el.parser.AstValue.getValue(AstValue.java:67)
at org.jboss.el.parser.AstDeferredExpression.getValue(AstDeferredExpression.java:26)
at org.jboss.el.parser.AstCompositeExpression.getValue(AstCompositeExpression.java:31)
at org.jboss.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:186)
at com.sun.facelets.el.TagValueExpression.getValue(TagValueExpression.java:71)
at org.richfaces.component.html.HtmlModalPanel.getOnhide(HtmlModalPanel.java:596)
at sun.reflect.GeneratedMethodAccessor609.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at javax.faces.component.UIComponentBase$AttributesMap.get(UIComponentBase.java:1609)
at org.richfaces.renderkit.ModalPanelRendererBase.initializeResources(ModalPanelRendererBase.java:148)
at org.richfaces.renderkit.html.ModalPanelRenderer.doEncodeBegin(ModalPanelRenderer.java:189)
at org.richfaces.renderkit.html.ModalPanelRenderer.doEncodeBegin(ModalPanelRenderer.java:178)
at org.ajax4jsf.renderkit.RendererBase.encodeBegin(RendererBase.java:100)
at javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:816)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:928)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:933)
at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:592)
at org.ajax4jsf.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:100)
at org.ajax4jsf.application.AjaxViewHandler.renderView(AjaxViewHandler.java:176)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:110)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:646)
at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:438)
Aug 28, 2013 3:29:25 PM org.apache.catalina.core.StandardHostValve custom
SEVERE: Exception Processing ErrorPage[errorCode=500, location=/de/system/500.xhtml]
javax.servlet.ServletException: javax.el.ELException: /de/fragmente/basic_modalpanel.xhtml @21,60 onhide="document.location.reload(true);#{profilViewHelper.setLastLoginDate()}": org.jboss.seam.core.LockTimeoutException: could not acquire lock on @Synchronized component: profilViewHelper
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:277)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:646)
at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:438)
at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:374)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:302)
at org.apache.catalina.core.StandardHostValve.custom(StandardHostValve.java:421)
at org.apache.catalina.core.StandardHostValve.status(StandardHostValve.java:342)
at org.apache.catalina.core.StandardHostValve.throwable(StandardHostValve.java:286)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:141)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:615)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:311)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:776)
at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:705)
at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:898)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)
at java.lang.Thread.run(Thread.java:662)
15:30:00,440 WARN [ThreadPoolAsynchronousRunner] com.mchange.v2.async.ThreadPoolAsynchronousRunner$DeadlockDetector@71f670d8 -- APPARENT DEADLOCK!!! Creating emergency threads for unassigned pending tasks!
15:30:43,068 WARN [ThreadPoolAsynchronousRunner] com.mchange.v2.async.ThreadPoolAsynchronousRunner$DeadlockDetector@71f670d8 -- APPARENT DEADLOCK!!! Complete Status:
Managed Threads: 3
Active Threads: 3
Active Tasks:
com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask@5a5dd88c (com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#2)
com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask@4733fdad (com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#0)
com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask@26538d60 (com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#1)
Pending Tasks:
com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask@3766ad48
com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask@35fa6e62
com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask@4c64ff9d
com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask@7ac9c399
com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask@5448b0c9
com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask@704e8759
com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask@33981da9
com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask@47c35cb5
com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask@6afb93e1
com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask@2aa9cfa6
com.mchange.v2.resourcepool.BasicResourcePool$1RefurbishCheckinResourceTask@727fb12b
com.mchange.v2.resourcepool.BasicResourcePool$1RefurbishCheckinResourceTask@1d48b8c7
com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask@115b1fd6
com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask@75872380
com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask@7b2be4c7
com.mchange.v2.resourcepool.BasicResourcePool$1RefurbishCheckinResourceTask@7eb903fd
com.mchange.v2.resourcepool.BasicResourcePool$1RefurbishCheckinResourceTask@24b5180a
com.mchange.v2.resourcepool.BasicResourcePool$1RefurbishCheckinResourceTask@6d3d4b59
com.mchange.v2.resourcepool.BasicResourcePool$1RefurbishCheckinResourceTask@531df816
com.mchange.v2.resourcepool.BasicResourcePool$1RefurbishCheckinResourceTask@548a96fb
com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask@56be6419
com.mchange.v2.resourcepool.BasicResourcePool$1RefurbishCheckinResourceTask@6d9dd1cc
com.mchange.v2.resourcepool.BasicResourcePool$1RefurbishCheckinResourceTask@1438e04d
com.mchange.v2.resourcepool.BasicResourcePool$1RefurbishCheckinResourceTask@220de99a
com.mchange.v2.resourcepool.BasicResourcePool$1RefurbishCheckinResourceTask@3f638eed
com.mchange.v2.resourcepool.BasicResourcePool$1RefurbishCheckinResourceTask@213c8a1e
com.mchange.v2.resourcepool.BasicResourcePool$1RefurbishCheckinResourceTask@d8fc89e
com.mchange.v2.resourcepool.BasicResourcePool$1RefurbishCheckinResourceTask@5abc0406
com.mchange.v2.resourcepool.BasicResourcePool$1RefurbishCheckinResourceTask@6dac5473
com.mchange.v2.resourcepool.BasicResourcePool$1RefurbishCheckinResourceTask@4cdc8245
com.mchange.v2.resourcepool.BasicResourcePool$1RefurbishCheckinResourceTask@20eca76f
Pool thread stack traces:
Thread[com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#2,5,main]
com.mchange.v2.resourcepool.BasicResourcePool.setLastAcquisitionFailure(BasicResourcePool.java:194)
com.mchange.v2.resourcepool.BasicResourcePool.access$1000(BasicResourcePool.java:32)
com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask.run(BasicResourcePool.java:1834)
com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:547)
Thread[com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#0,5,main]
com.mchange.v2.resourcepool.BasicResourcePool.setLastAcquisitionFailure(BasicResourcePool.java:194)
com.mchange.v2.resourcepool.BasicResourcePool.access$1000(BasicResourcePool.java:32)
com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask.run(BasicResourcePool.java:1834)
com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:547)
Thread[com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#1,5,main]
com.mchange.v2.resourcepool.BasicResourcePool.doAcquire(BasicResourcePool.java:1026)
com.mchange.v2.resourcepool.BasicResourcePool.access$800(BasicResourcePool.java:32)
com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask.run(BasicResourcePool.java:1810)
com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:547)
15:30:43,268 INFO [ProfilViewHelper] LoginDate changed
15:32:10,805 INFO [ProfilViewHelper] Try save login date from user: Wed Aug 28 15:32:10 CEST 2013
15:32:10,859 INFO [DBConnectionManager] connection leased (new created): 57eae7ac, PoolSize: 1
15:32:10,871 WARN [ThreadPoolAsynchronousRunner] Task com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask@5a5dd88c (in deadlocked PoolThread) failed to complete in maximum time 60000ms. Trying interrupt().
15:32:10,874 WARN [ThreadPoolAsynchronousRunner] Task com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask@4733fdad (in deadlocked PoolThread) failed to complete in maximum time 60000ms. Trying interrupt().
15:32:56,467 INFO [ProfilViewHelper] LoginDate changed
15:32:56,515 WARN [DBConnectionManager] Retry (counter: 1) to create a new connection due to com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
The last packet successfully received from the server was 29 milliseconds ago. The last packet sent successfully to the server was 29 milliseconds ago., PoolSize: -1
15:32:56,516 INFO [ProfilViewHelper] Try save login date from user: Wed Aug 28 15:32:56 CEST 2013
0 -
Author: andre - 8/28/2013 15:53
aus den log kann ich leider nicht viel erkennen, ausser das ein DeadlockDetector aktiv ist.
deshalb habe ich schon zuvor geschrieben:
---------
wenn das problem des tomcats auftritt, mal einen dump machen.
mittels jstack [java-process-pid]
statt der jconsole mal jvisualvm nutzen (wird auch mit dem jdk installiert) und unter threads schauen welcher die cpu-zeit verbraucht. auf dem threads-tab kann man auch einen threaddump machen.
---------
* nur um das nochmal klar zu stellen: der FS-Server läuft ohne Probleme ... korrekt?
* und "abschmieren" heisst "hängen" nicht "crashen" auch korrekt?
also:
mittels "jps" die pid des java-prozesses raussuchen
dann einen "jstack [java-process-pid] > dump.txt"
und:
was ist http://www.mchange.com/projects/c3p0/ bzw. com.mchange.v2.resourcepool..... ist das wirklich noetig? oder einfachmal ohne testen?
evtl. diese lib mal rausnehmen?
-------------
15:30:00,440 WARN [ThreadPoolAsynchronousRunner] com.mchange.v2.async.ThreadPoolAsynchronousRunner$DeadlockDetector@71f670d8 -- APPARENT DEADLOCK!!! Creating emergency threads for unassigned pending tasks!
15:30:43,068 WARN [ThreadPoolAsynchronousRunner] com.mchange.v2.async.ThreadPoolAsynchronousRunner$DeadlockDetector@71f670d8 -- APPARENT DEADLOCK!!! Complete Status:
Managed Threads: 3
Active Threads: 3
Active Tasks:
-------------
0 -
Author: mlieber - 9/24/2013 8:04
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 -
Author: der_sk - 9/25/2013 13:24
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.... :smileyhappy:
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 -
Author: mlieber - 9/26/2013 12:18
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 -
Author: mlieber - 9/26/2013 12:51
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 -
Author: der_sk - 9/26/2013 13:08
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 -
Author: linde - 9/26/2013 13:40
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 -
Author: mlieber - 10/10/2013 14:02
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 -
Author: thmarx - 10/11/2013 8:26
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 -
Author: nilsweber - 6/19/2014 14:31
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
0
Vous devez vous connecter pour laisser un commentaire.
Commentaires
18 commentaires