Home / Maintenance notes: keeping media jobs from exhausting memory
Maintenance notes: keeping media jobs from exhausting memory
This collection shares a Linux host with a separate media service. On October 2, 2026, an investigation found repeated memory kills in that service. These notes describe the mismatch, its repair and what the next measurements could establish.
The mismatch
The old media container had a 768 MiB memory limit, but its temporary filesystem allowed about 1,500 MB. Downloads could be as large as 400 MB and three workers could run concurrently. Media in a memory-backed filesystem was charged alongside Node, extraction processes and ffmpeg. Separate inputs, merge output and several workers made those limits a poor fit.
The old container showed 113 accumulated restarts and an OOM-killed flag. Kernel records showed repeated memory-limit kills. This was strong evidence of a reliability problem, but did not prove that every failed request or the site’s search decline shared that cause.
The repair
Media output now uses persistent disk-backed storage. Temporary process files are limited to 64 MiB, the memory limit is 1.5 GiB and one download worker runs at a time. Two metadata requests may run concurrently. Additional accepted downloads queue rather than immediately launching more extraction workers.
Storage admission reserves room for video and audio inputs plus merged output. Low space rejects a new job before charging quota. Cleanup protects active work and removes failed partial files. A durable job index preserves completed links across restarts without extending their original expiration.
The next observations
The October 3 audit found no kernel OOM entries after the deployment cutoff. The current container was healthy and had no restarts since creation. It used roughly 73 MiB at idle and 94 MiB after small functional tests. These short-period observations do not establish the maximum memory needed for every file.
| Logged metric | Before | After |
|---|---|---|
| Completed downloads | 36 | 38 |
| Completed output | 1,346 MiB | 1,491 MiB |
Separate fresh tests completed a short YouTube MP4 and MP3 in nine to ten seconds, a SoundCloud MP3 in eleven seconds and a short TikTok MP4 in about five seconds. File endpoints returned nonempty output with the expected MIME types and sizes. These four tests occurred after the comparison window and are excluded from its totals.
What the numbers do not prove
The completion log omits failed attempts, so it cannot establish a success-rate percentage. Diagnostic jobs can appear alongside normal activity. Demand and file sizes vary, and there is no comparable earlier timing test. The rise in completed output is descriptive evidence rather than a controlled throughput measurement. The old restart count covered a longer period, whereas the new container’s count reset when it was created.
Several older platform samples still failed. Recently successful TikTok, Instagram and Facebook inputs passed metadata extraction, illustrating why a bad fixture does not establish a complete platform outage. The narrower conclusion is useful: the storage and concurrency hazard was repaired, current core jobs completed, and memory, failures and cleanup still need ongoing observation.
For visitors
A queue is preferable to a crash, but can mean waiting for another job. Provider restrictions remain separate from server capacity. The SaveVideo guide explains that difference. The status page records the scope of checks across the wider collection without claiming universal compatibility.