Jira behind Apache sometimes slow

[Aleks]

Our Jira is running behind a apache (reverse proxy). Sometimes Jira is running very slow. Apache is throwing the following errors.

Does anyone know how to fix this?

[Tue Jan 08 15:36:56.160575 2019] [proxy_http:error] [pid 3180:tid 1052] (OS 10060)A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.... 

[proxy:error] [pid 3180:tid 1052] [client 10.172.21.128:2543] AH00898: Error reading from remote server returned ....

[Nic Brough -Adaptavist- · Accepted solution]

It means what it says - the Jira server is not responding to requests from the proxy.

You'll need to have a look at the Jira server to see why it is slow and non-responsive.

[Aleks]

well, there are several log-lines. after a restart of the jira service today, everything worked well.

There is something about a memory leak in the jirasoftware.log and GC overhead limit exceeded in atlassian.jira.log.

Am I right?

jirasoftware{date}.log

09-Jan-2019 12:54:32.370 WARNING [localhost-startStop-2] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [jira] appears to have started a thread named [JonasClock] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread:
java.lang.Thread.sleep(Native Method)
org.objectweb.jonas_timer.TimerManager.clock(TimerManager.java:142)
org.objectweb.jonas_timer.Clock.run(TimerManager.java:46)

04-Jan-2019 18:29:29.186 WARNING [http-nio-8080-exec-4] org.apache.catalina.connector.Response.setContentType The encoding [binary] is not recognised by the JRE
java.lang.IllegalArgumentException: java.io.UnsupportedEncodingException: The character encoding [binary] is not supported
at org.apache.coyote.Response.setCharacterEncoding(Response.java:417)
at org.apache.catalina.connector.Response.setContentType(Response.java:810)

Atlassian.jira.log

2019-01-08 15:11:03,568 http-nio-8080-exec-68 ERROR Aleks 910x20815x2 dvfx7w {ip,ip} /rest/webResources/1.0/resources [c.a.p.r.c.error.jersey.ThrowableExceptionMapper] Uncaught exception thrown by REST service: GC overhead limit exceeded
java.lang.OutOfMemoryError: GC overhead limit exceeded
2019-01-08 15:34:14,842 Caesium-1-3 INFO ServiceRunner [c.a.j.p.h.service.ping.RefreshConnectionStatusJobHandler] Running RefreshConnectionStatusJobHandler...
2019-01-08 15:34:22,891 Caesium-1-2 INFO ServiceRunner [c.a.j.p.h.service.connect.InstallGlancesJobHandler] Running InstallGlancesJobHandler...
2019-01-08 15:34:22,892 Caesium-1-2 INFO ServiceRunner [c.a.j.p.h.service.connect.InstallGlancesJobHandler] The plugin is not configured, no need to install glances.
2019-01-08 16:34:14,843 Caesium-1-1 INFO ServiceRunner [c.a.j.p.h.service.ping.RefreshConnectionStatusJobHandler] Running RefreshConnectionStatusJobHandler...
2019-01-08 16:34:22,892 Caesium-1-3 INFO ServiceRunner [c.a.j.p.h.service.connect.InstallGlancesJobHandler] Running InstallGlancesJobHandler...
2019-01-08 16:34:22,897 Caesium-1-3 INFO ServiceRunner [c.a.j.p.h.service.connect.InstallGlancesJobHandler] The plugin is not configured, no need to install glances.

Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded
at sun.awt.image.ByteInterleavedRaster.getDataElements(ByteInterleavedRaster.java:323)
at java.awt.image.BufferedImage.getRGB(BufferedImage.java:917)
at sun.awt.image.OffScreenImageSource.sendPixels(OffScreenImageSource.java:175)
at sun.awt.image.OffScreenImageSource.produce(OffScreenImageSource.java:187)
at sun.awt.image.OffScreenImageSource.addConsumer(OffScreenImageSource.java:66)
at java.awt.image.FilteredImageSource.startProduction(FilteredImageSource.java:183)
at sun.awt.image.ImageRepresentation.startProduction(ImageRepresentation.java:732)
at sun.awt.image.ImageRepresentation.drawToBufImage(ImageRepresentation.java:807)
at sun.java2d.pipe.DrawImage.copyImage(DrawImage.java:1021)
at sun.java2d.pipe.ValidatePipe.copyImage(ValidatePipe.java:186)
at sun.java2d.SunGraphics2D.drawImage(SunGraphics2D.java:3318)
at sun.java2d.SunGraphics2D.drawImage(SunGraphics2D.java:3296)
at com.atlassian.core.util.thumbnail.Thumber.scaleImage(Thumber.java:190)
at com.atlassian.core.util.thumbnail.Thumber.scaleImage(Thumber.java:227)
at com.atlassian.core.util.thumbnail.Thumber.scaleImage(Thumber.java:201)
at com.atlassian.jira.avatar.AvatarPickerHelperImpl.cropImageToFile(AvatarPickerHelperImpl.java:316)
at com.atlassian.jira.avatar.AvatarPickerHelperImpl.clampSize(AvatarPickerHelperImpl.java:284)
at com.atlassian.jira.avatar.AvatarPickerHelperImpl.upload(AvatarPickerHelperImpl.java:117)
... 3 filtered
at java.lang.reflect.Method.invoke(Method.java:498)
at com.atlassian.plugin.util.ContextClassLoaderSettingInvocationHandler.invoke(ContextClassLoaderSettingInvocationHandler.java:26)
at com.sun.proxy.$Proxy195.upload(Unknown Source)
... 3 filtered
at java.lang.reflect.Method.invoke(Method.java:498)
at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:302)
at org.eclipse.gemini.blueprint.service.importer.support.internal.aop.ServiceInvoker.doInvoke(ServiceInvoker.java:56)
at org.eclipse.gemini.blueprint.service.importer.support.internal.aop.ServiceInvoker.invoke(ServiceInvoker.java:60)

[Nic Brough -Adaptavist-]

Yes, the GC error is probably the culprit, as Jira will run slow before doing it and then die as it happens.

The important log here is the atlassian-jira.log, but a GC error is serious, it means there is something wrong with the memory settings, or you don't have the resources or run the system, or there is a memory leak, or, or, or...

You'll need to investigate and monitor this for further occurrences, and probably tune it - start at https://confluence.atlassian.com/enterprise/garbage-collection-gc-tuning-guide-461504616.html

[Aleks]

Thank you very much!

As a short term solution I increased the Heap Memory.

I had also a closer look at Troubleshooting and support tools.

The performance issues could be caused by some mail issues.

• OutOfMemory due to Large Mailbox Processing
• OutOfMemory due to Mail Loop
• OutOfMemory due to Custom Services
• JIRA applications crash due to OutOfMemoryError Java heap space
• Mail Queue Must Be Flushed Manually due to OutOfMemoryError

The strange thing is, we don't have any Custom Services and no mail handler (at least not for jira). we are using jira service desk and the Create Issue from Mail is handled by Jira Service Desk.

[Berk Atlasian]

We have the same problem. Did you find permanent solution?

[Aleks]

We switched to Jira Cloud :-) 

I think our problem was an email loop. After increasing the heap and deleting the mail loop, it worked fine.

Cheers

Aleks