Where: internal/config/config.go line 303 and internal/imageprocessor/imageprocessor.go line 188 (default max_concurrent_processing is the CPU count pixa sees); internal/imgcache/service.go lines 453-460 (a whole source stays in memory while its request waits for a slot); README.md "Running under upaas" (line 106) and max_concurrent_processing (line 586), on v1.0.0-rc1.
What is wrong: one transcode of an 8192x8192 source, the documented input cap, decodes to 200-540 MB, and WebP, AVIF and JPEG XL hold the whole output in memory too, so one slot can take about 0.5-1.2 GB. The default slot count is the number of CPUs pixa sees, and containers on the shared host run without CPU or memory flags (#158): on a 48-CPU host that is 48 slots, tens of GB in the worst case, plus up to upstream_connections (64) sources of upstream_max_response_size (50 MiB) each waiting for a slot. None of this is in "Running under upaas", which lists the port, the volume, three variables and the health check.
How it fails: with a host carrying user content allowlisted (the example config allowlists one), an outsider uploads a few 8192x8192 PNGs of a few KB each and requests them at distinct sizes; each request costs about a GB while it runs, and the shared host runs out of memory before it runs out of CPU.
Severity: high
Definition of done:
README.md "Running under upaas" gives the worst-case memory (slots times the per-image bound, plus connections times upstream_max_response_size) and tells the operator to set PIXA_MAX_CONCURRENT_PROCESSING and PIXA_UPSTREAM_CONNECTIONS to fit the memory the container may use.
The default slot count no longer follows the host's CPU count when no CPU limit is set: a small fixed default, or one from a memory budget; the implementer proposes, the reviewer and owner decide.
make check green.
Model: fable-5-1
Where: `internal/config/config.go` line 303 and `internal/imageprocessor/imageprocessor.go` line 188 (default `max_concurrent_processing` is the CPU count pixa sees); `internal/imgcache/service.go` lines 453-460 (a whole source stays in memory while its request waits for a slot); `README.md` "Running under upaas" (line 106) and `max_concurrent_processing` (line 586), on `v1.0.0-rc1`.
What is wrong: one transcode of an 8192x8192 source, the documented input cap, decodes to 200-540 MB, and WebP, AVIF and JPEG XL hold the whole output in memory too, so one slot can take about 0.5-1.2 GB. The default slot count is the number of CPUs pixa sees, and containers on the shared host run without CPU or memory flags (https://git.eeqj.de/sneak/pixa/issues/158): on a 48-CPU host that is 48 slots, tens of GB in the worst case, plus up to `upstream_connections` (64) sources of `upstream_max_response_size` (50 MiB) each waiting for a slot. None of this is in "Running under upaas", which lists the port, the volume, three variables and the health check.
How it fails: with a host carrying user content allowlisted (the example config allowlists one), an outsider uploads a few 8192x8192 PNGs of a few KB each and requests them at distinct sizes; each request costs about a GB while it runs, and the shared host runs out of memory before it runs out of CPU.
Severity: high
Definition of done:
1. `README.md` "Running under upaas" gives the worst-case memory (slots times the per-image bound, plus connections times `upstream_max_response_size`) and tells the operator to set `PIXA_MAX_CONCURRENT_PROCESSING` and `PIXA_UPSTREAM_CONNECTIONS` to fit the memory the container may use.
2. The default slot count no longer follows the host's CPU count when no CPU limit is set: a small fixed default, or one from a memory budget; the implementer proposes, the reviewer and owner decide.
3. `make check` green.
Model: fable-5-1
clawbot
self-assigned this 2026-10-13 08:46:09 +02:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Where:
internal/config/config.goline 303 andinternal/imageprocessor/imageprocessor.goline 188 (defaultmax_concurrent_processingis the CPU count pixa sees);internal/imgcache/service.golines 453-460 (a whole source stays in memory while its request waits for a slot);README.md"Running under upaas" (line 106) andmax_concurrent_processing(line 586), onv1.0.0-rc1.What is wrong: one transcode of an 8192x8192 source, the documented input cap, decodes to 200-540 MB, and WebP, AVIF and JPEG XL hold the whole output in memory too, so one slot can take about 0.5-1.2 GB. The default slot count is the number of CPUs pixa sees, and containers on the shared host run without CPU or memory flags (#158): on a 48-CPU host that is 48 slots, tens of GB in the worst case, plus up to
upstream_connections(64) sources ofupstream_max_response_size(50 MiB) each waiting for a slot. None of this is in "Running under upaas", which lists the port, the volume, three variables and the health check.How it fails: with a host carrying user content allowlisted (the example config allowlists one), an outsider uploads a few 8192x8192 PNGs of a few KB each and requests them at distinct sizes; each request costs about a GB while it runs, and the shared host runs out of memory before it runs out of CPU.
Severity: high
Definition of done:
README.md"Running under upaas" gives the worst-case memory (slots times the per-image bound, plus connections timesupstream_max_response_size) and tells the operator to setPIXA_MAX_CONCURRENT_PROCESSINGandPIXA_UPSTREAM_CONNECTIONSto fit the memory the container may use.make checkgreen.Model: fable-5-1