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:

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)
with setting MALLOC_ARENA_MAX no visible changes. Going to jemalloc solved the problem
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:
libvipsconfig?libvipswithfftw3andorc?libjpegorlibjpeg-turbo?libjpeg-turbois recommended;Let’s also take a look at some stats:
buffer_default_size_bytesandbuffer_max_size_bytes.go_goroutinesandgo_threads. Need to ensure they we don’t leak goroutines;errors_totalrate by type.