How do I fix ImageMagick cache resources exhausted?

Raise the limits in policy.xml, or override them for one run with -limit memory 4GiB -limit map 8GiB -limit disk 16GiB. Check the current values with magick -list resource.

Why does ImageMagick say width or height exceeds limit?

The image is larger than the width or height limit in policy.xml, which defaults to 16000 pixels. This is most often caused by converting a large PDF page at too high a -density.

How do I limit ImageMagick memory usage?

Use -limit memory with a value, or set the MAGICK_MEMORY_LIMIT environment variable. In containers set this explicitly, because ImageMagick reads host memory rather than the cgroup limit.

cache resources exhausted / width or height exceeds limit

ImageMagick resource limits live in policy.xml. How to see the current limits, raise them safely, and why an oversized -density on a PDF is usually the real cause.

convert: cache resources exhausted `input.jpg' @ error/cache.c/OpenPixelCache/4083
convert: width or height exceeds limit `input.png' @ error/cache.c/OpenPixelCache/3742
convert: DistributedPixelCache `127.0.0.1' @ error/distribute-cache.c

What is happening

ImageMagick enforces limits on memory, disk, area and pixel dimensions so that a maliciously crafted image cannot exhaust the host. Like the PDF block, these live in policy.xml and were tightened considerably after a run of denial-of-service reports.

See the current limits

magick -list resource

Resource limits:
  Width: 16KP        Height: 16KP       Area: 128MP
  Memory: 256MiB     Map: 512MiB        Disk: 1GiB
  Thread: 8          Time: unlimited

16KP means 16,000 pixels. A photo that exceeds any single limit fails.

Before raising anything — check your density

The most common trigger is not a huge photograph. It is a PDF converted at a density that does not match the page size:

magick -density 600 poster.pdf out.png

An A0 poster at 600 DPI is around 80,000 pixels wide — roughly 20 gigapixels. That is not a limit worth raising; the density is simply wrong. For screen use, 150 is plenty. See the PDF page for a density guide.

Raise the limits

Edit the domain="resource" lines in policy.xml (find it with magick -list policy):

<policy domain="resource" name="memory" value="4GiB"/>
<policy domain="resource" name="map" value="8GiB"/>
<policy domain="resource" name="disk" value="16GiB"/>
<policy domain="resource" name="area" value="512MP"/>
<policy domain="resource" name="width" value="64KP"/>
<policy domain="resource" name="height" value="64KP"/>

Or for a single run, without editing anything

magick -limit memory 4GiB -limit map 8GiB -limit disk 16GiB \
  input.tif -resize 2000 output.jpg

Environment variables work too, which is handy in CI:

export MAGICK_MEMORY_LIMIT=4GiB
export MAGICK_DISK_LIMIT=16GiB
export MAGICK_AREA_LIMIT=512MP

How the memory and disk limits interact

ImageMagick keeps the pixel cache in memory up to the memory limit, then memory-maps a file up to map, then falls back to plain disk up to disk. Setting memory low and disk high does not fail — it gets slow, sometimes dramatically. If a job that should take seconds takes minutes, you are probably thrashing the disk cache.

Setting disk to 0 forces failure rather than a slow fallback, which is a reasonable choice on a server where predictable latency matters more than completing every job.

Reduce the work instead

Read at reduced size. For JPEG, ImageMagick can decode directly at a fraction: magick -define jpeg:size=2000x2000 huge.jpg -resize 1000 out.jpg. This never allocates the full-size image.
Use -thumbnail. It pre-scales before the full resize, using far less memory than -resize.
Limit threads. -limit thread 2. Each thread carries its own overhead, and on a memory-constrained container fewer threads can be faster.
Process pages individually. For a large multi-page PDF, loop over input.pdf[n] rather than loading every page at once.

In containers

ImageMagick reads the host's memory, not the container's cgroup limit, so it will happily try to allocate more than the container is allowed and get OOM-killed. Set the limits explicitly in your Dockerfile or entrypoint rather than relying on the defaults.