Resources and performance
What S5W consumes, what that depends on and which variables control it. The defaults are sized for a small server; raise them for load.
Memory
The container runs PostgreSQL and several application processes: the supervisor, the HTTP request process, the scheduler and the panel. At idle the application processes take about 200 MB.
The main consumer is request handling under load. An upload chunk and image processing
are megabytes in memory, which is why the process has a 512 MiB ceiling
(SERVER_MEMORY_LIMIT). For a small server 2 GB of RAM is enough; leave room for PostgreSQL
and the OS page cache — it speeds up delivery of frequently requested files.
Warning at start-up
If the container has a memory limit (--memory, mem_limit) and the application’s memory
ceiling does not fit into it, the application logs a Memory over-commit warning with the
calculation. It does not block the start — it is a worst-case estimate.
SERVER_MEMORY_LIMIT
What it does. The memory ceiling of one application process, in PHP format: 512M, 1G.
Default — 512M. Going lower is not advisable: an upload chunk of up to 16 MiB and
processing an image of up to 25 megapixels need headroom.
What happens when it is exceeded. The request that hit the ceiling fails, and the process is restarted — the other parts of the service keep working.
Do not set -1
-1 does not remove the limit, it hands it over to the OS kernel: on overuse the OOM killer
kills the process — with no log entry and possibly together with the whole container. The
application warns about this at start-up.
SERVER_REQUEST_TIMEOUT
What it does. How many seconds a request may wait before the server interrupts it. An
interrupted request gets 504, and the operations it started are closed properly.
Default — 30. 0 — no limit.
What it does not interrupt. Slow file delivery: downloading a large file over a slow connection is not cut by the timeout. The timeout protects against requests stuck waiting.
When to change it. Almost never. If clients upload chunks over a very slow connection and
get 504, raise the value or reduce the chunk size on the client.
Request size
| What | Limit | What happens above it |
|---|---|---|
| The body of one request to the application | 32 MiB | 413, the body is not accepted |
A file in one request, POST /v1/files |
about 32 MiB including the form fields | 413 |
| An upload chunk | 4–16 MiB | 400 / 413 with an explanation |
The 32 MiB limit is built in and not configurable: larger files are uploaded in chunks. The panel does that by itself for files over 16 MiB.
A proxy in front of the service must let through a body of at least 32 MiB — see Behind a reverse proxy.
Disk
- Files take exactly as much as their unique content: duplicates use no space.
- Chunked uploads sit in
staging/while in transfer — as much as has arrived so far. Abandoned ones are deleted 24 hours after their last chunk. - A 512 MiB reserve. A chunked upload does not start if less than 512 MiB would be left on
the disk after it: the answer is
507. This protects the database — PostgreSQL stops on a full disk. - The database is usually small compared to the files: metadata and daily statistics for a year.
Watch the free space on the volume from outside — see monitoring.
CPU
The main CPU load is computing SHA-256 on upload and processing images. File delivery barely uses the CPU. Compression of API responses is on for text responses from 1 KiB.