Hello @qdegraeve,

Could you share some details about the sample images you used? For example, progressive JPEGs will need a lot of memory to process.

I made a tiny test program:

#!/usr/bin/ruby
require 'vips'
target_width = ARGV[0].to_i
ARGV[1..].each do |filename|
 thumb = Vips::Image.thumbnail(filename, target_width)
 dirname = File.dirname filename
 basename = File.basename filename, ".*"
 output_filename = "#{dirname}/thumb_#{basename}.jpg"
 puts "writing #{output_filename} ..."
 thumb.write_to_file output_filename
end

I used this test image (6k x 4k JPEG, 1.2mb):

nina

I made a test dataset like this:

$ mkdir sample
$ cd sample
$ for i in {1..19}; do cp ~/pics/nina.jpg $i.jpg; done

Then ran the thumbnailer like this:

$ /usr/bin/time -f %M:%e ./thumb3.rb 200 sample/*
writing sample/thumb_10.jpg ...
writing sample/thumb_11.jpg ...
writing sample/thumb_12.jpg ...
writing sample/thumb_13.jpg ...
writing sample/thumb_14.jpg ...
writing sample/thumb_15.jpg ...
writing sample/thumb_16.jpg ...
writing sample/thumb_17.jpg ...
writing sample/thumb_18.jpg ...
writing sample/thumb_19.jpg ...
writing sample/thumb_1.jpg ...
writing sample/thumb_2.jpg ...
writing sample/thumb_3.jpg ...
writing sample/thumb_4.jpg ...
writing sample/thumb_5.jpg ...
writing sample/thumb_6.jpg ...
writing sample/thumb_7.jpg ...
writing sample/thumb_8.jpg ...
writing sample/thumb_9.jpg ...
97800:0.89

So it made the 19 thumbnails in 900ms and needed a peak of 98mb of memory.

There's little concurrency in thumbnailing, so you can turn off the libvips threadpool and save some time and memory. This makes a relatively big difference on this PC since it has 32 hardware threads. You'll see less of a change on typical machines:

$ VIPS_CONCURRENCY=1 /usr/bin/time -f %M:%e ./thumb3.rb 200 sample/*
writing sample/thumb_10.jpg ...
...
writing sample/thumb_9.jpg ...
78792:0.59

78mb peak and 600ms.

If you run with no images, you can see the startup cost:

$ VIPS_CONCURRENCY=1 /usr/bin/time -f %M:%e ./thumb3.rb 200 
53756:0.11

So starting ruby and libvips needs 54mb and 110ms. Subtracting the two, the actual image processing is around 24mb and 500ms.

I looked at the original issue more carefully and I think your graphs might not be including subprocesses, could that be correct?

mini_magick works by generating imagemagick command lines and executing them in subprocesses. It's called mini_magick because this approach minimises the memory use of the calling ruby process. Of course you still need memory for processing, it's just less visible.

You can make a little shell script that reproduces this behaviour, for example:

#!/bin/bash
for filename in $*; do
 echo processing $filename ...
 for size in 910x650 200x150; do
 convert $filename -resize ${size} $filename-$size.jpg
 done
done

The bash process will see little memory use, it'll all be in the convert process that's being run. I think this is what your minimagick graph is showing.

If I run that script ^^ on 15 of your test images I see:

$ /usr/bin/time -f %M:%e ../thumb3.sh *
processing 10.jpg ...
...
processing 1.jpg ...
processing 2.jpg ...
processing 3.jpg ...
processing 4.jpg ...
processing 5.jpg ...
processing 6.jpg ...
processing 7.jpg ...
processing 8.jpg ...
processing 9.jpg ...
344616:18.53

So it takes 18.5s and needs a peak of 350mb of memory (/usr/bin/time will include memory used in subprocesses). The ruby-vips benchmark above was 24mb peak and 500ms runtime, so memory use is a lot lower overall.

You could speed up the convert script using a define to exploit libjpeg shrink on load, though I don't know if mini_magick does this, it'd be interesting to see the exact command it's generating.

One drawback of ruby-vips is that the heavy processing is happening directly in your web server process. While it's quick, this has two big downsides:

1. Security. If there's a bad bug in one of the image load libraries that libvips uses (for example, libpng), your web server process could be attacked with a crafted file.

   To mitigate this, I would set the VIPS_BLOCK_UNTRUSTED env var. You could also consider a separate ruby process for image handling, but perhaps that's only worthwhile for very large sites.

2. Memory fragmentation. A lot of active low level threaded code in your process will cause memory fragmentation with many malloc implementations. I would either live with it, or look into something like jemalloc.

Hi @jcupitt ,

thanks a lot for your help and all the tips you gave me. I have try to build a docker image with your script inside and run it and there was no issue at all. The memory usage graph stayed very flat.

In the meantime I saw another github thread where you said that on debian build-essentials package was mandatory and that was not the case for me. Do you think this could be the cause of the memory peaks ?

Hi again,

I did some more tests and I fear that the problem is still here. I think I just badly tested last time or had a false positive.
I did a lot of tests , trying with ruby-vips directly with the help of the script you gave me, trying with the image-processing gem as in my rails application.

There is no difference in memory usage with the scripts and at the end they all have a peak of memory around 500 mb for the processing of 60 images of 3 mb each.

I noticed something interesting. When I run the script I see no memory issue. When I run the code in a rails console, the memory usage increase but seems to never get released until I shut down the console. As you can see in the graph below.

Could there be a memory leak in the ruby-vips gem ? I doubt of that but I ask the question anyway ...