활성 트랜스코딩 작업을 중지하고, 임시 세그먼트가 기록되는 위치를 확인한 다음 정리 작업을 적용하고 경로를 시스템 드라이브에서 분리하세요.
소스 라이브러리가 대용량 스토리지 풀에 있어도 미디어 서버는 기본 캐시 또는 애플리케이션 디렉터리 아래에 HLS 세그먼트, 리먹스된 스트림, 자막 번인 출력 파일, 완료되지 않은 세션 파일을 저장할 수 있습니다. 이러한 파일이 충분히 빠르게 삭제되지 않거나 트랜스코딩 디렉터리가 잘못 매핑되었거나 재생 종료 후 중단된 세션이 남아 있으면 시스템 드라이브가 가득 찹니다. 파일을 삭제하거나 캐시를 이전하기 전에 실제 디렉터리와 세션을 진단하세요.
활성 트랜스코딩 디렉터리와 가장 큰 세션 찾기
제어된 트랜스코딩을 하나 시작하고 어느 디렉터리의 크기가 증가하는지 확인하세요. 애플리케이션 설정, 컨테이너 경로, 호스트 바인드 마운트, 파일 시스템, 사용 가능한 공간, 파일 수, 가장 큰 세션 하위 디렉터리를 기록하세요.
Jellyfin은 임시 트랜스코딩 파일을 위한 별도의 쓰기 가능한 위치를 제공하므로, 트랜스코딩 경로가 영구 미디어 라이브러리 및 메타데이터 경로와 분리되어 있음을 확인할 수 있습니다. 관련 설정은 임시 트랜스코딩 경로입니다.
애플리케이션에 표시되는 경로와 호스트 드라이브가 가득 차는 위치가 다르면 Docker의 실제 마운트와 쓰기 가능 계층을 점검하세요. 바인드 마운트가 누락되면 컨테이너가 의도한 캐시 볼륨 대신 시스템이 지원하는 컨테이너 파일 시스템에 임시 파일을 기록할 수 있습니다.
긴급 정리 전에 생성 프로세스 중지
활성 재생 세션을 확인하고 빠르게 증가하는 파일과 관련된 트랜스코딩만 중지하세요. 공간을 확보하기 전에 최신 FFmpeg 로그, 소스 제목, 클라이언트, 출력 비트레이트, 자막, 시작 시간을 저장하세요.
과거에는 재생이 끝난 후에도 오래된 트랜스코딩 파일이 남아 디스크가 가득 차고 서버를 시작할 수 없게 된 사례가 있었습니다. Jellyfin 이슈에는 사용자가 시청을 중단한 후에도 몇 시간 동안 트랜스코딩 임시 폴더를 계속 점유한 영화가 기록되어 있습니다.
FFmpeg가 아직 파일을 기록하는 동안 활성 세션에 속한 파일을 삭제하지 마세요. 세션 또는 서버를 정상적으로 중지하고 파일이 더 이상 열려 있지 않은지 확인한 다음, 캐시 전체나 애플리케이션 데이터베이스가 아니라 임시 출력으로 확인된 파일만 삭제하세요.
장시간 스트리밍 세션을 위한 세그먼트 삭제 활성화
재생 중 서버가 다운로드된 HLS 세그먼트를 삭제하는지 확인하세요. 세그먼트 삭제가 없으면 긴 영화나 라이브 스트림에서 생성된 전체 출력을 보관할 만큼의 디스크 공간이 필요할 수 있습니다.
Jellyfin은 클라이언트가 다운로드한 후 오래된 세그먼트를 삭제하면 서버가 트랜스코딩된 파일 전체를 저장할 필요가 없다고 설명합니다. 이 옵션은 특히 전체 스트림 저장 방지를 위해 존재합니다.
테스트 클라이언트에서 이 기능을 활성화하고 재생, 탐색, 이어보기를 모니터링하세요. 보관된 세그먼트가 필요한 재현 가능한 클라이언트 문제가 있을 때만 비활성화하고, 더 큰 전용 트랜스코딩 볼륨과 더욱 엄격한 세션 정리로 보완하세요.
트랜스코딩 경로를 전용 고속 볼륨으로 이동
운영 체제 루트와 분리된 전용 SSD, NVMe 캐시 또는 충분한 크기의 임시 파일 시스템을 선택하세요. 대상 위치는 동시 쓰기를 감당할 수 있어야 하며 예상되는 최악의 트랜스코딩 세션을 수용할 만큼 충분한 용량을 갖춰야 합니다.
소형 RAM 디스크에 트랜스코딩을 저장한 사용자들은 디렉터리가 임시 장치를 가득 채울 때까지 계속 증가할 수 있어 캐시 제한을 요청해 왔습니다. 백업 장치가 RAM인지 SSD인지와 관계없이 문제의 경계는 제한 없는 트랜스코딩 캐시입니다.
서버를 중지하고 올바른 서비스 소유권으로 새 디렉터리를 만든 다음, 컨테이너에 명시적으로 매핑하고 애플리케이션 설정을 컨테이너에서 접근 가능한 경로로 업데이트하세요. 트랜스코딩을 하나 실행하고 호스트 시스템 드라이브의 사용량이 더 이상 증가하지 않는지 확인하세요.
오래된 세션과 정리 실패 찾기
임시 세션 디렉터리를 활성 재생 세션 ID 및 FFmpeg 프로세스와 비교하세요. 일치하는 세션이 없고 실행 중인 프로세스가 없으며 수정 시간이 오래된 파일은 지원되는 정리 대상일 수 있습니다.
일반적인 캐시 정리 작업이 모든 트랜스코딩 산출물을 삭제한다고 가정하지 마세요. 이전 Jellyfin 정리 보고서에서는 일반 캐시 작업이 오래된 트랜스코딩 파일을 삭제하지 못한 것으로 나타났으므로, 실제로 확인해야 할 사항은 세션별 정리가 완료되었는지입니다.
클라이언트 연결 해제, 컨테이너 재시작, 충돌, 네트워크 손실, 강제 프로세스 종료 전후의 서버 로그를 검토하세요. 유일한 제어 수단으로 매일 삭제 스크립트에 의존하지 말고, 서버가 정상적인 중지 이벤트를 받지 못하게 하는 원인을 해결하세요.
최악의 동시 트랜스코딩 사용량 측정
대표적인 원격 트랜스코딩을 하나 실행하고 분당 임시 데이터 사용량을 측정하세요. 자막 번인, HDR 톤 매핑, 지원되는 가장 높은 출력 비트레이트 조건에서도 반복한 다음, 계획한 동시 세션 수와 보관 시간에 맞춰 계산하세요.
시스템 드라이브가 가득 차면 재생 외에도 미디어 서버에 영향을 줄 수 있습니다. Jellyfin 지원 사례에서는 드라이브를 가득 채운 트랜스코딩이 웹 인터페이스 연결 불가와 관련 있을 수 있다고 언급했으며, 이는 시스템 볼륨 고갈이 애플리케이션 가용성에 영향을 준다는 점을 보여줍니다.
운영 체제, 로그, 데이터베이스, 패키지 업데이트, Docker 메타데이터를 위한 여유 공간을 확보하세요. 트랜스코딩 볼륨은 서버 부팅이나 미디어 애플리케이션 실행을 막지 않고 독립적으로 가득 차도록 구성해야 합니다.
정리 확인 및 용량 알림 추가
재생 시작, 탐색, 일시 정지, 클라이언트 연결 해제, 서버 재시작, 동시 세션을 테스트하세요. 활성 파일이 전용 트랜스코딩 경로에서만 증가하고 세션이 끝난 후 감소하는지 확인하세요.
ZimaSpace의 홈 미디어 서버 구축 가이드는 소스 스토리지를 애플리케이션 및 임시 작업과 분리하는 전체 검증 절차를 제공합니다.
오래된 세션이 더 이상 남지 않고, 지원되는 클라이언트에서 세그먼트 삭제가 작동하며, 시스템 드라이브에 안전한 여유 공간이 유지되고, 전용 트랜스코딩 볼륨이나 루트 파일 시스템이 용량 임계값에 도달하기 전에 알림이 작동하면 복구가 완료된 것입니다.
지원 및 팁
더 읽어보기

Docker 볼륨을 복원하면 파일 내용은 복원되지만 확장 속성은 사라지는 이유는 무엇인가요?
xattr 인벤토리, tar 및 Rsync 옵션, 네임스페이스, 대상 지원, 권한, 레이블, 앱 메타데이터와 테스트를 다루는 볼륨 복원 진단.

Compose 파일을 변경한 후에도 실행 중인 컨테이너의 메모리 제한이 기존 값으로 유지되는 이유는 무엇인가?
실행 중인 cgroup, 재시작과 재생성, Compose 필드, 하드 및 소프트 제한, 상위 범위, 스왑, 런타임 힙을 다루는 메모리 제한 진단입니다.

리버스 프록시를 재시작하면 셀프 호스팅 앱 하나의 모든 세션이 무효화되는 이유는 무엇인가요?
재시작 범위, 쿠키 소유권, 비밀 키 순환, 캐시 기반 세션, 스티키 라우팅, 인증 게이트웨이 및 복구를 다루는 세션 손실 진단.

