imgproxy: Memory leaks imgproxy v2.1.3 ?

During the day at an average load of ~200 rpm there is a constant growth of rss memory. What memory consumption is normal for imgproxy ? I use imgproxy v2.1.3 on bare metal with dev-lang/go-1.10.1

Settings:

IMGPROXY_BIND=127.0.0.1:8080
IMGPROXY_LOCAL_FILESYSTEM_ROOT=/home/project/static
IMGPROXY_ENABLE_WEBP_DETECTION=true
IMGPROXY_PROMETHEUS_BIND=127.0.0.1:9080
IMGPROXY_CONCURRENCY=10
IMGPROXY_MAX_CLIENTS=20

Some graphs: image image image

Sample processing: 2018/12/18 16:53:46 | 200 | [P6qFfmvtKhatZE6zNCtFu5] Processed in 49.943965ms: local:///sn037/images/product/193/762/606_original.jpg; &{Resize:fill Width:200 Height:200 Dpr:1 Gravity:{Type:soea X:0 Y:0} Enlarge:false Format:webp Quality:80 Flatten:false Background:{R:255 G:255 B:255} Blur:0 Sharpen:0 CacheBuster: Watermark:{Enabled:false Opacity:1 Replicate:false Gravity:ce OffsetX:0 OffsetY:0 Scale:0} UsedPresets:[]}

libvips v8.7.2 build options:

native win32:                           no
native OS X:                            no
open files in binary mode:              no
enable debug:                           no
enable deprecated library components:   yes
enable docs with gtkdoc:                no
gobject introspection:                  no
enable vips7 C++ API:                   no (default)
enable vips7 Python binding:            no (default)
enable vips8 Python overrides:          no (default)
  (requires pygobject-3.13.0 or later)
enable radiance support:                yes
enable analyze support:                 yes
enable PPM support:                     yes

* optional dependencies
use fftw3 for FFT:                      no
Magick package:                         MagickCore
Magick API version:                     magick6
load with libMagick:                    yes
save with libMagick:                    yes
accelerate loops with orc:              no
  (requires orc-0.4.11 or later)
ICC profile support with lcms:          no
file import with niftiio:               no
file import with OpenEXR:               no
file import with OpenSlide:             no
  (requires openslide-3.3.0 or later)
file import with matio:                 no
PDF import with PDFium                  no
PDF import with poppler-glib:           no
  (requires poppler-glib 0.16.0 or later)
SVG import with librsvg-2.0:            no
  (requires librsvg-2.0 2.34.0 or later)
zlib:                                   yes
file import with cfitsio:               no
file import/export with libwebp:        yes
  (requires libwebp-0.1.3 or later)
support webp metadata:                  yes
  (requires libwebpmux-0.5 or later)
text rendering with pangoft2:           no
file import/export with libpng:         yes (pkg-config libpng >= 1.2.9)
  (requires libpng-1.2.9 or later)
support 8bpp PNG quantisation:          no
  (requires libimagequant)
file import/export with libtiff:        no
file import/export with giflib:         yes (found by search)
file import/export with libjpeg:        yes (pkg-config)
image pyramid export:                   no
  (requires libgsf-1 1.14.26 or later)
use libexif to load/save JPEG metadata: no

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Reactions: 4
  • Comments: 29 (29 by maintainers)

Most upvoted comments

with setting MALLOC_ARENA_MAX no visible changes. Going to jemalloc solved the problem

image

Well, I’m literally out of ideas. Our instances go on their average memory usage for a long time. Let’s collect some more info about your installation:

  • What’s your latest libvips config?
  • Could you build libvips with fftw3 and orc?
  • Do you use libjpeg or libjpeg-turbo? libjpeg-turbo is recommended;
  • Which Go version do you currently use? Did you try to upgrade to the latest version?

Let’s also take a look at some stats:

  • Latest Go memstats. Need to ensure it doesn’t grow unexpectedly;
  • buffer_default_size_bytes and buffer_max_size_bytes.
  • go_goroutines and go_threads. Need to ensure they we don’t leak goroutines;
  • errors_total rate by type.