New Package: Umbraco.Community.Imaging.ImageSharp

AaronSadlerUK · August 4, 2026, 2:25pm

I’ve released a package as an interim fix for memory issues when running Umbraco on Docker with memory limits, it targets V13, V17 and V18

You can read the issue here:

github.com/umbraco/Umbraco-CMS

Media: Image processing is OOM-killed in memory-limited containers when browsing the media section

opened 11:18AM - 04 Aug 26 UTC

AaronSadlerUK

### Which Umbraco version are you using? 17.6.1 (also reproduces on earlier maj…ors — see #16226) ### Bug summary On a host with a hard memory limit — a Linux container, most commonly — browsing the media section grows memory until the process is killed by the OOM killer (exit code 137). Windows hosts are not affected in the same way. The cause is not a leak. `ImageSharpMiddleware` decodes the source image at full resolution before any processor runs, and it only de-duplicates concurrent requests for the **same** URL. A media grid renders a screenful of *distinct* thumbnails, so every source decodes in parallel with no ceiling. Peak memory is therefore `concurrent requests × decoded source size`, which is unbounded. Measured on a 4000×3000 JPEG source, a single 300×300 thumbnail request costs **+60 MB peak RSS** (measured via `VmHWM`, one request, no concurrency). Sixteen concurrent thumbnail requests is ~960 MB, which exceeds a 512 MB container limit and the process is killed within seconds. Two secondary factors make the memory look like a leak in monitoring: 1. ImageSharp's `UniformUnmanagedMemoryPoolMemoryAllocator` sizes its pool at `GC.GetGCMemoryInfo().TotalAvailableMemoryBytes / 8` and trims only on a gen2 collection, at most 50% per 60 s unless memory load exceeds 90%. Measured: 176 MB still held at idle in a 2 GB container, surviving a *forced* gen2 collection. 2. The pool blocks come from `Marshal.AllocHGlobal` (= `malloc`). `malloc_trim(0)` released a further 20–45 MB that GC alone did not — glibc retention, which is why Windows behaves differently. Both are **unmanaged** memory, which is why `DOTNET_GC*` settings have no effect on this. That matches the reports in #16226, where changing GC mode did not help. Separately, `memory.current` for the cgroup is inflated by page cache from MediaCache writes (measured 1016 MB cgroup vs 441 MB process RSS), so monitoring overstates the problem. The kernel does reclaim that under pressure, so it is not the thing that kills the container. ### Specifics Environment used to reproduce: - `mcr.microsoft.com/dotnet/aspnet:10.0-noble` (Ubuntu 24.04), cgroup v2 - SixLabors.ImageSharp 3.1.12, SixLabors.ImageSharp.Web 3.2.0 (the versions in `Directory.Packages.props` for 17.6.1) - ImageSharp wired exactly as `AddUmbracoImageSharp()` does: `ClearProviders()`, `WebRootImageProvider`, Umbraco's `CropWebProcessor`, `ConfigureImageSharpMiddlewareOptions`, `PhysicalFileSystemCache` Container exit state: ``` container: exited oomkilled=true exit=137 ``` Behaviour against container memory limit, 40 source JPEGs of 4000×3000 (~9.5 MB each), every request a distinct crop/resize so every request is a cache miss: | memory limit | concurrency | result | |---|---|---| | 512m | 1 | stable, 167 MB RSS | | 512m | 8 | survives, peak 453 MB | | 512m | 16 | **OOMKilled, exit 137, within 5 s** | Steady state at a 2 GB limit, concurrency 8, idle after two bursts of load: | | idle RSS | pooled unmanaged | |---|---|---| | default | 409 MB | 176 MB (44 handles × 4 MB) | | `MaximumPoolSizeMegabytes = 32` | 251 MB | 16–32 MB | ### Steps to reproduce On a clean Umbraco install running in a Linux container: 1. Run the site in Docker with a memory limit, e.g. `--memory=512m`. Ubuntu-based `mcr.microsoft.com/dotnet/aspnet` images reproduce this; Windows hosting does not. 2. Upload a few dozen large images to the media section — 4000×3000 JPEGs (~9–10 MB) reproduce it reliably. Camera/DSLR uploads from a real site are typical. 3. Browse the media section page by page, so each page requests a screenful of *distinct* thumbnails that are not yet in the media cache. 4. Watch container memory (`docker stats`) climb with each page. The container is OOM-killed once a page's worth of concurrent thumbnail requests, on top of memory not yet released from previous pages, crosses the limit. Increasing the number of thumbnails rendered per page, or the source image dimensions, reaches it faster. A minimal standalone reproduction that isolates this from the rest of the CMS (a small ASP.NET Core app configured identically to `AddUmbracoImageSharp()`, plus the load and measurement scripts) is available if useful — happy to attach it. ### Expected result / actual result **Expected:** memory used for image processing stays bounded relative to the memory available to the process, so browsing the media section cannot take the site down. A site under a container limit should degrade in throughput, not be killed. **Actual:** peak memory scales with the number of images being processed concurrently, with no ceiling, and the process is OOM-killed (exit 137). --- I have a fix ready and will open a PR shortly. It adds an `Umbraco:CMS:Imaging:Memory` settings section with two values, both defaulting to `0` meaning "derive from the memory available to the process": - `MaximumPoolSizeMegabytes` — caps the unmanaged pool ImageSharp retains between requests - `MaximumConcurrentProcessing` — caps how many images are processed at once, enforced by a new middleware registered ahead of `UseImageSharp()` Verified against the exact load that produced exit 137 (512 MB limit, concurrency 16): the container now survives with peak RSS 285 MB and idle 189 MB, deriving `poolMB=16 maxConcurrent=3` on that host. Warm-cache throughput is unaffected. This is related to #16226, which was closed as an external dependency issue. The underlying behaviour is ImageSharp's, but the concurrency ceiling is something Umbraco can set on the caller side without replacing `IImageUrlGenerator`/`IImageDimensionExtractor`, so it seems worth fixing in the CMS.

You can grab the package here:

NuGet Gallery | Umbraco.Community.Imaging.ImageSharp 1.1.0.

#Umbraco #NuGet