Jellyfin이 예상보다 더 많은 임시 데이터를 보관하는 원인은 무엇인가요?

Jellyfin은 트랜스코딩, 캐시, 생성된 미디어 산출물, 정리 작업이 모두 서로 다른 수명 주기를 따르기 때문에 예상보다 많은 임시 데이터를 유지할 수 있습니다.

캐시나 임시 디렉터리가 커진다고 해서 자동으로 누수인 것은 아닙니다. 일부 파일은 활성 세션에 속하고, 일부는 재사용 가능한 파생 상태이며, 일부는 보관 기간이나 일정 임계값을 기다리고, 일부는 정리 전에 작업이 종료되어 남아 있습니다. 먼저 생성 주체와 수명 주기를 진단하세요. 원인을 알 수 없는 디렉터리를 삭제하면 증거가 사라지거나 비용이 큰 재생성을 강제할 뿐, 근본 원인을 해결하지 못할 수 있습니다.

근본 원인은 단순히 큰 캐시가 아니라 수명 주기의 불일치입니다

임시 데이터가 의심스러워지는 시점은 관찰된 수명이 해당 데이터를 만든 이벤트와 더 이상 일치하지 않을 때입니다. 트랜스코딩 작업 집합은 재생 활동을 따라야 하고, 재사용 가능한 썸네일이나 트릭플레이 데이터는 의도적으로 한 세션보다 오래 남을 수 있으며, 정리 작업이 관리하는 파일은 타이머나 임계값이 만료될 때까지 남아 있을 수 있습니다. 모든 경로가 “임시”로 보여도 이들은 서로 다른 계약입니다.

리소스 사용량이 높은 경우에 대한 Jellyfin 문제 해결 지침은 활성 트랜스코딩과 다른 백그라운드 작업을 구분합니다. 따라서 남은 파일을 고아 파일로 간주하기 전에 활성 트랜스코딩을 확인해야 합니다. 아직 소유자가 있고 실제 사용자가 접근 중인 파일은 크다는 이유만으로 오래된 파일이 아닙니다.

문제가 되는 조건은 원인을 설명할 수 없는 증가입니다. 활성 생성 주체가 해당 데이터를 필요로 하지 않고, 재사용 정책상 보관할 이유도 없으며, 언제 사라져야 하는지 예측할 정리 규칙도 없는 경우입니다. 이 세 가지 설명이 모두 성립하지 않으면, 남아 있는 임시 데이터는 파생 미디어 처리에 따른 정상적인 비용이 아니라 운영상의 결함이 됩니다.

남아 있는 임시 데이터의 네 가지 원인

파일을 삭제하기 전에 생성 주체를 기준으로 분류하세요. 유용한 범주는 활성 세션 데이터, 재사용 가능한 파생 산출물, 정책에 따른 정리를 기다리는 파일, 중단된 작업이 남긴 고아 중간 파일입니다. 각 범주마다 안전하게 삭제할 수 있는 시점이 다릅니다.

기간 기반 정리 시스템은 “지금 사용하지 않음”과 “삭제할 수 있음”이 같지 않은 이유를 보여 줍니다. 보관은 타임스탬프, 규칙, 예약된 정리 작업에 연결될 수 있기 때문입니다. 따라서 기간 기반 정리 규칙은 수명 주기 정책과 즉시 필요한 세션 상태를 구분하는 데 유용한 모델입니다.

아래 네 가지 특징을 활용해 증가가 예상된 것인지, 지연된 것인지, 고아 상태인지 판단하세요. 디렉터리에 일회성 작업 파일이 들어 있는지, 아니면 재생성해도 같은 용량을 다시 차지할 재사용 가능한 산출물이 들어 있는지 알기 전에는 전체 크기 임계값을 적용하지 마세요.

원인 1: 활성 트랜스코딩이 여전히 작업 집합을 소유하고 있음

• 메커니즘: 진행 중이거나 최근 종료된 재생 세션이 임시 세그먼트를 기록하며, 트랜스코딩 파이프라인이 이를 해제할 때까지 계속 필요로 합니다.
• 증상 특징: 파일 수정 시간과 디렉터리 증가는 활성 트랜스코딩 세션 또는 최근 탐색 동작과 함께 변합니다.
• IF–THEN: 모든 트랜스코딩이 종료된 뒤 작업 집합의 변경이 멈추고 해제된다면, 이를 고아 파일이 아니라 세션에 종속된 데이터로 간주하세요.

원인 2: 재사용 가능한 파생 산출물이 의도적으로 지속됨

• 메커니즘: 썸네일, 트릭플레이 이미지, 메타데이터 또는 기타 생성된 표현이 이후 클라이언트에서 재사용될 수 있기 때문에 보존됩니다.
• 증상 특징: 파일이 여러 세션에 걸쳐 안정적으로 남아 있고 탐색이나 이동 중 다시 읽힙니다. 따라서 트릭플레이 및 메타데이터 파일은 한 세션에서만 사용하는 임시 데이터보다 캐시 가능한 파생 상태에 가깝게 동작할 수 있습니다.
• IF–THEN: 파일을 삭제해도 예측 가능한 재생성만 일어나고 장기적인 용량이 줄지 않는다면, 반복적으로 삭제하기보다 생성 및 보존 정책을 관리하세요.

원인 3: 정리 작업이 기간 또는 예약된 실행 조건에 아직 도달하지 않음

• 메커니즘: 생성 주체는 작업을 끝냈지만, 삭제를 담당하는 별도의 정리 프로세스가 나중에 실행됩니다.
• 증상 특징: 재생이나 분석이 끝난 직후가 아니라, 일정한 시각이나 기간 임계값에 도달했을 때 오래된 파일이 묶음으로 사라집니다.
• IF–THEN: 보존 기간이 문서화되었거나 관찰된 정리 시간 범위와 일치한다면, 디스크 여유 공간 때문에 더 짧은 기간이 필요할 때만 정책을 조정하세요.

원인 4: 중단된 작업이 고아 중간 파일을 남김

• 메커니즘: 프로세스가 임시 파일을 만든 뒤 충돌하거나 강제 종료되거나, 정리 작업이 실행되지 않는 경로로 종료됩니다.
• 증상 특징: 오래된 파일에 활성 소유자가 없고 재사용 패턴도 없으며, 중단된 작업 시점에 타임스탬프가 집중되어 있습니다. 실제 자동화 실패 사례는 중단 후 정리가 건너뛰어지면 대규모 작업 디렉터리가 쌓일 수 있음을 보여 줍니다.
• IF–THEN: 동일한 작업이 취소되거나 실패할 때마다 파일을 남긴다면, 먼저 종료 시 정리 작업을 수정한 다음 확인된 고아 파일 집합만 삭제하세요.

실패 경계: 예상된 보존과 비정상적인 증가를 구분하는 방법

디렉터리 크기만으로 판단하지 마세요. 파일의 기간 분포, 최근 수정 활동, 활성 Jellyfin 세션, 예약된 작업, 의심스러운 각 파일을 여전히 열어 둔 프로세스를 기록하세요. 예상된 보존에는 소유자나 규칙이 있습니다. 비정상적인 증가에는 둘 다 없거나 규칙을 반복적으로 초과합니다.

파일 시스템 회계도 진단을 오도할 수 있습니다. Linux에서는 프로세스가 삭제된 파일을 계속 열어 두는 동안 해당 파일이 디스크 블록을 계속 사용할 수 있습니다. 따라서 보이는 경로 이름이 사라진 뒤에도 삭제된 파일이 디스크 공간을 차지할 수 있습니다. `df`와 디렉터리 합계가 일치하지 않는다면 데이터를 더 삭제하기 전에 열린 파일 디스크립터를 확인하세요.

생성 주체가 사라지고, 예상된 정리 시간이 지났으며, 파일이 재사용 가능한 파생 상태도 아니고, 수동으로 삭제한 뒤에도 용량이 계속 증가하거나 다시 나타난다면 경계를 넘어선 것입니다. 이때 캐시 크기만 변경하는 것은 증상만 다루는 방법입니다. 데이터를 생성하고, 닫고, 무효화하고, 삭제하는 수명 주기를 수정하세요.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

정리하기 전에 임시 데이터 원장을 작성하세요

용량이 큰 각 임시 경로에 대해 생성 주체, 데이터 역할, 활성 소유자, 가장 오래된 수정 시간과 가장 최근 수정 시간, 재사용 신호, 예상 정리 조건, 현재 크기, 안전한 삭제 조건을 간단한 원장으로 작성하세요. 그러면 “캐시가 너무 크다”는 말이 검증 가능한 진술로 바뀌고, 이후 증가량을 알려진 기준선과 비교할 수 있습니다.

ZimaSpace의 읽기-쓰기 작업 분리에 대한 설명은 적극적으로 생성되는 데이터와 단순히 재사용되는 데이터를 구분하는 데 도움이 됩니다. 파일 소유자가 확실하지 않다면 Linux 프로세스 검사를 통해 정리 작업으로 증거가 바뀌기 전에 어떤 프로세스가 파일을 열어 두고 있는지 확인할 수 있습니다.

원장이 삭제 가능한 파일 집합을 식별하고 생성 주체가 더 이상 이를 사용하지 않을 때만 정리 결정을 실행하세요. 확인된 소규모 샘플을 삭제하고 Jellyfin의 동작을 확인한 다음 정리 규칙을 적용하세요. 디렉터리가 즉시 같은 안정 상태의 크기로 다시 증가한다면, 끝없는 삭제 작업을 예약하기보다 생성 주체나 보존 정책을 조정하세요.