Memory leak / no Garbage Collection in DServer?

[Simon]

Hi all,

Has anyone noticed memory leaks using ruby-dicom DServer? While receiving multiple dicom MR Enhanced multiframe studies, I see memory creep up continuously. I have not found an upper limit, but for my limited test of 23 studies, real memory usage (as inspected with OSX Activity Monitor) rose from about 200MB to 1.6GB .

It would seem memory is not being released with the regular ruby garbage collection for some reason, or not quickly enough, but it seems to be a ruby-dicom specific problem, not an MRI ruby issue. I tried the same experiment with JRuby and sure enough, I ran out of java heap space at around 500MB.

Unfortunately I know next to nothing about debugging memory leaks, so I can be of little help. Perhaps someone in the group is more experienced.

Simon

[Christoffer Lervåg]

Indeed, such technical programming issues are not amongst my strong sides either. That's one of the reasons I like Ruby as a programming language, it allows you to get things done in a very elegant manner, not having to worry about low level things like garbage collection.

It seems Im doing something wrong with the DServer code then, memory wise. If some of the more Ruby-savvy members of this forum would like to have a look at this, please feel free to do so! A shortcut to the DServer code:

https://github.com/dicom/ruby-dicom/blob/master/lib/dicom/d_server.rb#L180

On a related note, there has been an idea to rewrite the network code of ruby-dicom for quite some time now. This project, will refactor the code to make it simpler/more object oriented, and will use a third party library for handling the network traffic (possibly Celluloid::IO). I've never wanted to give a promise as to the start of this work, as I've always felt that it is far away, but now I feel that I might get a chance to start work on this after the summer. This project will, if successful, probably increase the performance of the DICOM server considerably.

Best regards,

Chris

Simon

--
You received this message because you are subscribed to the Google Groups "ruby-dicom" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ruby-dicom+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Marc Kohli]

It's probably not directly related, but I recently had a project that used ruby-dicom to manipulate hundreds of CR and DR image objects from a single directory.  I was easily filling the ram of my small VM, and blowing the java heap of a jruby process when using  DICOM.load(directory).

To fix this, I set up some basic datamapper classes for studies, patients, and instances and used a local sqlite database for persistence.

In order to populate my data model I used:

    in_dir = File.join(settings.root, "data", config.input_directory, "**/*.dcm")

    Dir.glob(in_dir).each do |f|

      logger.info("processing file: #{f}.")

      load_images(f)

    end

where load_images calls DICOM.load on individual instances.

--Marc

[Simon]

Marc, indeed, loading images from files in ruby dicom works great. For the project I presented at SIIM, I loaded the DICOM files into CouchDB using the 'parallel' gem, which was truly a delight to use (highly reccomended, filled up all 8 cores on my machine, blazing fast). Ruby DICOM behaves beautifully during the load, and memory never climbs more than the usual ruby process ( about 100mb. Granted, ruby is not the most resource-friendly language).

However, your approach and mine may help point away from a problem involving the basic DICOM processing in ruby-dicom, and more towards the networking code in the DServer. As Chris mentioned, a threaded aproach to networking like Celluloid::IO may take care of this and provide additional performance. 

I will try to study a little bit of ruby parallelized networking on my (limited) spare time so I can hopefully give Chris a hand when he decides to take on that rewrite. 

Cheers,

Simon