We're Hiring!

OMERO 5.1.4 Fiji Plugin behaviour vs Java heap space usage

General user discussion about using the OMERO platform to its fullest. Please ask new questions at https://forum.image.sc/tags/omero
Please note:
Historical discussions about OMERO. Please look for and ask new questions at https://forum.image.sc/tags/omero

There are workflow guides for various OMERO functions on our help site - http://help.openmicroscopy.org

You should find answers to any basic questions about using the clients there.

OMERO 5.1.4 Fiji Plugin behaviour vs Java heap space usage

Postby rhamedy » Fri Nov 06, 2015 4:28 pm

Hi guys,

We are thinking of replacing our network drive (storing images) with an OMERO server (as image repository) and I wanted to do a bit of analysis to find out how OMERO 5.1.4 plugin for Fiji behave when opening Images from OMERO rather than a network drive.

I configured the jstatd in our server and connect Java VisualVM to monitor both server performance as well as client performance of Fiji in OSX El Capitan (running Java 1.8).

I figured out that every time I open images via OMERO 5.1.4 plugin in Fiji, the Java heap space usage keeps rising (I have a 10 GB Ram and 8 threads Fiji settings) until the upload finishes. Once the upload finished, the Java heap space usage stays the same (does not drop) and as soon as I open another image via OMERO 5.1.4 plugin, then Java heap space usage keeps rising again ... see the rises underlined with a line (marked as A).

Screen Shot 2015-11-06 at 15.35.42.png
ImageJ 1.50d
Screen Shot 2015-11-06 at 15.35.42.png (148.17 KiB) Viewed 1912 times


When opening images (located in network drive) from the file menu of Fiji app, the Java heap space usage keeps rising until upload is completed. Once the upload is complete then it stays steady (even if you close the image windows, etc.) and as soon as you try to upload another image (from network drive directly to Fiji) there is a sudden drop (marked as C - circles) in usage of the Java heap space and I believe that is the garbage collection. This drop happens nearly every time a new image is uploaded to Fiji directly from network drive, meaning that probably garbage collection is triggered when starting new upload. The same is not true if you open images via the OMERO plugin from OMERO server, there is no sudden drop except for when the Java heap space usage reaches nearly 8.x GB (marked as B).

I started doing this comparison after someone said that their Fiji slows down after 30 minutes of work on it. I just wanted to know how the garbage collection takes place when images are opened via the OMERO plugin in Fiji?

I used tiff files of size 2.x to 6.x GB in size.

Note: Opening a 6.x GB file directly in Fiji give exception shown below (Probably because not enough memory). Opening the same 6.x GB images stored in OMERO server via OMERO 5.1.4 plugin to Fiji works fine.
Screen Shot 2015-11-06 at 12.24.55.png
Importing 6.x GB tiff to Fiji
Screen Shot 2015-11-06 at 12.24.55.png (119.65 KiB) Viewed 1912 times
rhamedy
 
Posts: 17
Joined: Mon Nov 02, 2015 10:27 am

Re: OMERO 5.1.4 Fiji Plugin behaviour vs Java heap space usa

Postby dgault » Tue Nov 10, 2015 9:25 am

Hi Raf,

Thanks for the detailed report and information. This is an issue which we have been investigating recently as we had seen reports of similar behaviour. The root cause was due to a memory leak when viewing composite images, in short when the image window was closed and garbage collection called the image data was still being referenced.

I have submitted a fix for this to Image J and it will be included in the latest ImageJ daily build (1.50e18).
You can view the relevant changes here: https://github.com/imagej/imagej1/commi ... f5de13ce1e

Thanks again for the feedback and hopefully this will resolve your issues going forward.
David Gault
User avatar
dgault
Team Member
 
Posts: 208
Joined: Fri Aug 14, 2015 2:56 pm

Re: OMERO 5.1.4 Fiji Plugin behaviour vs Java heap space usa

Postby rhamedy » Tue Nov 10, 2015 12:23 pm

Hi David,

Thank you for the quick fix. What you explained makes perfect sense, it was unfair to blame the GC for this.

Raf.
rhamedy
 
Posts: 17
Joined: Mon Nov 02, 2015 10:27 am


Return to User Discussion

Who is online

Users browsing this forum: No registered users and 1 guest