Project

General

Profile

Bug #7907

Elog crash on java out of heap memory

Added by Kyle Hazelwood almost 6 years ago. Updated almost 6 years ago.

Status:
Closed
Priority:
Immediate
Category:
Server
Target version:
-
Start date:
02/19/2015
Due date:
% Done:

0%

Estimated time:
Spent time:
Duration:

Description

The elog began crashing tonight on java heap memory problems. The problem seems to be with reading image files with ImageIO and then trying to create thumbnails of them.

elog_crash.log (16.6 MB) elog_crash.log Original crash catalina.out log file Kyle Hazelwood, 02/19/2015 10:13 PM
ElogHeapErrorOldWay.PNG (50.7 KB) ElogHeapErrorOldWay.PNG Heap memory profile of the problem Kyle Hazelwood, 02/20/2015 10:16 PM
ElogHeapErrorNewWayFinal.PNG (46.5 KB) ElogHeapErrorNewWayFinal.PNG Heap memory profile of final solution Kyle Hazelwood, 02/20/2015 10:18 PM

Related issues

Related to Elog - Bug #4544: Elog thumbnail generator has trouble handling large jpeg filesClosed08/14/2013

History

#1 Updated by Kyle Hazelwood almost 6 years ago

  • Related to Bug #4544: Elog thumbnail generator has trouble handling large jpeg files added

#2 Updated by Kyle Hazelwood almost 6 years ago

The bug showed its head last year. We ended up increasing the heap memory to accomodate.

#3 Updated by Kyle Hazelwood almost 6 years ago

  • Status changed from New to Assigned

#4 Updated by Kyle Hazelwood almost 6 years ago

I've disabled image thumbnails for the night until I can look into a better way of generating these thumbnails.

#5 Updated by Kyle Hazelwood almost 6 years ago

I implemented a new elog image thumbnail creation scheme:
  • The elog originally would read in the entire file/image to determine its aspect ratio to scale the image. This is fine for small images of low resolution, the problem occurs when images are of high resolution and compressed. When compressed images are read they are uncompressed; a 5MB jpeg may be hundreds of MBs when uncompressed. The new way doesn't require reading the entire image to obtain the aspect ratio thus eliminating the primary cause of the heap memory problem
  • The old way relied on java graphics 2D rendering hints to lower the quality of the thumbnails to decrease their size and the load time on the client side. This worked fine but required more memory on the server side as it was still reading the entire image to do this. In the new way there is a sampling quality factor that determines the quality of the thumbnail image.
  • The new scheme determines how many rows/columns of pixels it must read based on the aspect ratio of the image and the sampling quality factor given.

https://www-bd.fnal.gov/Elog/?entryIDs=44708

#6 Updated by Kyle Hazelwood almost 6 years ago

  • Status changed from Assigned to Closed

Also available in: Atom PDF